计划实现的bonus: - 缓存 - 并行 - GUI前端和完整部署方案 有时间打算实现的bonus(按优先级次序排序): 1. UTF-8中文支持 2. Validator 不打算实现的bonus: - 快照 - 文件系统修复 # 模块划分 整个程序分为后端和前端两部分,后端即主体部分 ## 后端 后端只有一个可执行文件,书店实例通过配置文件夹来决定(默认为当前目录下`.bookstore`文件夹,亦可通过命令行参数指定)。当书店系统在运行时,有且仅有一个后端进程,分为interactive模式(使用后端自带的交互,单会话模式)和server模式(通过WebUI交互)。 ### 数据库模块 维护相关数据,支持并行(API阻塞但可同时运行)。 #### 磁盘IO的并发 - 机械硬盘下不应该并发,反复寻址会负优化 - 从安全性角度,没有把握不要同时写 - 进程内部使用同一个文件描述符时,可以并发地调用读取函数,但是会自动相互阻塞 - 当使用不同的文件描述符时,并发调用读取函数时不会自动相互阻塞,如果并发读取的区域重叠,会有安全性问题 ~~因此我不太打算碰文件系统~~ #### 数据库设计方案 ##### 需求 ##### 数据结构 ##### 文件访问与缓存 ##### 并发安全 ### 引擎模块 具体执行业务,一次请求对应且只对应一次引擎模块API调用,支持并行(API阻塞但可同时运行)。当API入口函数被调用后,执行相关具体操作(包括会话管理),然后返回响应。 ### 通信与调度模块 负责对外提供文本模式的交互,以及维护请求级的并行。从流`request`读取文本格式的命令,并把内部数据格式的响应翻译成文本格式,向引擎模块发送请求(调用引擎模块对外提供的API),并把响应返回到流`response`。支持条件允许时的并行: - 输入子模块从`request`读取请求,打上时间戳,分独占式请求和可并行请求按时间戳顺序分批处理。处理一个请求时,启动一个工作线程调用翻译子模块。同一个会话的请求不可并行,把`std::thread`move进相应的该会话的工作线程句柄队列,下一个join前一个。成批执行可并行请求时,启动完当前批次所有工作线程后join每个session的最后一个工作线程,结束之后就可以执行下一批了。为了在服务模式下处理时有时无的请求,两个流在读取时是阻塞的(自己封装一个,用`std::condition_variable`通讯),并且读一个处理一个,碰到“不属于自己批次”的东西才算一批结束。 - 翻译子模块(入口函数本身阻塞)join完同一个session的上一个请求后,向引擎模块API发送请求,得到响应后把响应数据传给输出子模块的调用接口(阻塞但可并行,处理部分同时运行,上锁后直接输出到`response`,输出本身不同时进行)。 注意,在`request`流和`response`流中,输入输出仅保证单个请求/响应是完整的,多个请求/响应之间是完全“混杂”的,通过session token、operation token区分,通过outhentication key鉴权。`request`流和`response`流始终由信模块控制。注意,通讯模块不负责会话管理。 ### 内置交互模块 当处于server模式下,不负责会话管理,直接把`std::cin`和`std::cout`的内容转发给通信与调度模块;处于interactive模式下时,提供用户侧会话管理,然后再调用通信与调度模块。 标准输入输出始终由内置交互模块控制。 ## 前端 ~~不清楚有没有时间写~~。WebUI,采用`Node.JS`+`Socket.IO`,~~不打算弄得很好看,不打算支持响应式设计~~,支持图形化操作面板和“云命令行”。和interactive模式一样,单个会话的操作支持逻辑上并发(上一操作未结束可以发出下一操作)但后端实际上是串行的。对于通讯中断、偶发的服务器未响应,只保证不会彻底崩掉,不保证出问题的业务能恢复。会话管理方面,只负责信息准确投送。 ### 服务端 提供会话管理。虽然有log,但后端的响应只会发送一次,用于防止客户端掉线的缓存由服务端维护。 ### 客户端 云命令行和图形化操作面板分两个页面,通过超链接关联。历史记录、会话信息存储于IndexDB中。负责用户侧会话管理。 #### 云命令行 #### 图形化操作面板 实际上是一个页面,不同模式下动态绘制。