3.1 KiB
计划实现的bonus：
- 缓存
- 并行
- GUI前端和完整部署方案
有时间打算实现的bonus（按优先级次序排序）：
- UTF-8中文支持
- Validator
不打算实现的bonus：
- 快照
- 文件系统修复
模块划分
整个程序分为后端和前端两部分，后端即主体部分
后端
后端只有一个可执行文件，书店实例通过配置文件夹来决定（默认为当前目录下.bookstore文件夹，亦可通过命令行参数指定）。当书店系统在运行时，有且仅有一个后端进程，分为interactive模式(使用后端自带的交互，单会话模式)和server模式(通过WebUI交互)。
数据库模块
维护相关数据，支持并行（API阻塞但可同时运行）。
磁盘IO的并发
- 机械硬盘下不应该并发，反复寻址会负优化
- 从安全性角度，没有把握不要同时写
- 进程内部使用同一个文件描述符时，可以并发地调用读取函数，但是会自动相互阻塞
- 当使用不同的文件描述符时，并发调用读取函数时不会自动相互阻塞，如果并发读取的区域重叠，会有安全性问题
因此我不太打算碰文件系统
数据库设计方案
引擎模块
具体执行业务，一次请求对应且只对应一次引擎模块API调用，支持并行（API阻塞但可同时运行）。
通信模块
负责对外提供文本模式的交互，从流request读取文本格式的命令，并把内部数据格式的响应翻译成文本格式，向引擎模块发送请求（调用引擎模块对外提供的API），并把响应返回到流response。支持并行：
- 输入子模块从
request读取请求，启动一个线程调用翻译子模块。同一个会话的请求不可并行，把std::threadmove进相应的std::unordered_map<std::string,std::thread>，同一会话下次请求发出前，必须join完。 - 翻译子模块(入口函数本身阻塞)向引擎模块API发送请求，得到响应后把响应数据传给输出子模块的调用接口(阻塞但可并行，处理部分同时运行，上锁后直接输出到
response，输出本身不同时进行)。
注意，输入输出仅保证单个请求/响应是完整的，多个请求/响应之间是完全“混杂”的，通过session token、operation token区分，通过outhentication key鉴权。request流和response流始终由信模块控制。注意，通讯模块不负责会话管理。
内置交互模块
当处于server模式下，直接把std::cin和std::cout绑给通信模块；处于interactive模式下时，提供会话管理，然后再调用通信模块。
标准输入输出始终由内置交互模块控制。
前端
不清楚有没有时间写。WebUI，采用Node.JS+Socket.IO，不打算弄得很好看，不打算支持响应式设计，支持图形化操作面板和“云命令行”。和interactive模式一样，单个会话的操作不支持并行。对于通讯中断、偶发的服务器未响应，只保证不会彻底崩掉，不保证出问题的业务能恢复。
服务端
提供会话管理