docs: 基本完成技术架构设计
This commit is contained in:
@ -23,6 +23,9 @@
|
||||
- 进程内部使用同一个文件描述符时，可以并发地调用读取函数，但是会自动相互阻塞
|
||||
- 当使用不同的文件描述符时，并发调用读取函数时不会自动相互阻塞，如果并发读取的区域重叠，会有安全性问题
|
||||
|
||||
|
||||
一次IO的固定开销差不多相当于1e5条CPU指令或1e4次基本操作，以及相当于读入一块100KB~1MB的连续空间，可以考虑把分块链表的块级索引集中到开头的一个大块里。
|
||||
|
||||
~~因此我不太打算碰文件系统~~
|
||||
|
||||
#### 数据库设计方案
|
||||
@ -32,7 +35,7 @@
|
||||
###### 底层实现
|
||||
通过B+树或一个有序的块状链表实现一个键值数据库，相当于`std::multimap`，一个键值数据库实例拥有恰好一个文件
|
||||
###### 逻辑实现
|
||||
数据库的一条记录有主键（应当是唯一的）、副键和数据构成，从主键到数据建立multimap，从副键到主键建立multimap，一个数据库实例拥有恰好两个文件。
|
||||
数据库的一条记录有主键（应当是唯一的）、副键和数据构成，从主键到数据建立multimap，从副键到主键建立multimap，一个数据库实例拥有恰好两个文件，一个数据库可以有多个Sheet，用于逻辑上存储不同的表。
|
||||
|
||||
##### 文件访问与缓存
|
||||
memoryriver类维护一个缓存，简单地缓存高频访问和连续访问；键值数据库根据逻辑缓存最近访问和高频访问；数据库层不设缓存。
|
||||
@ -56,6 +59,8 @@ memoryriver类维护一个缓存，简单地缓存高频访问和连续访问；
|
||||
|
||||
## 前端
|
||||
~~不清楚有没有时间写~~。WebUI，采用`Node.JS`+`Socket.IO`，~~不打算弄得很好看，不打算支持响应式设计~~，支持图形化操作面板和“云命令行”。和interactive模式一样，单个会话的操作支持逻辑上并发（上一操作未结束可以发出下一操作）但后端实际上是串行的。对于通讯中断、偶发的服务器未响应，只保证不会彻底崩掉，不保证出问题的业务能恢复。会话管理方面，只负责信息准确投送。
|
||||
|
||||
~~不考虑卡死的情况，数据库卡死了也拿它没办法，引擎部分不死循环就不会卡死~~，只支持重置session。
|
||||
### 服务端
|
||||
提供会话管理。虽然有log，但后端的响应只会发送一次，用于防止客户端掉线的缓存由服务端维护。
|
||||
### 客户端
|
||||
|
||||
Reference in New Issue
Block a user