# kvs

**Repository Path**: youz17/kvs

## Basic Information

- **Project Name**: kvs
- **Description**: talent plan 的路径5
- **Primary Language**: Rust
- **License**: GPL-3.0
- **Default Branch**: rmp
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2020-07-01
- **Last Updated**: 2021-04-08

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# a key-value store


## 简介
> 当初是想挣扎下能不能去pingcap混个远程实习，然后一部分因为实力，一部分因为那阵子正好是期末，很多课结课作业多，所以就中途放弃了，但之后也无聊会写写。。。

> 具体介绍见: https://github.com/pingcap/talent-plan/tree/master/courses/rust

- 简单来说就是 key-value 数据库
- 目前只支持 string-string
- 分为服务器端和客户端，用 TCP 通信
- 暂且不支持多线程，但是快了（如果我写的话

### 更细节的实现
- 存储采用类似 *lfs* 的结构
- 正常退出（客户端使用 `quit` 命令）的话会构造索引
- 序列化使用 *messagepack*



## project-4

### 问题及思路
- 多线程如何处理同步
    - 理论上是可以同时读写的，即使是读写的 `key` 是相同的，写文件的时候，直接写入，然后更新索引，只在更新索引的时候加锁,但是这是假设没有 `buffer` 的情况
    - 很丢人的我忘记上面说的是啥了，目前是直接加锁，很粗暴
- 如何处理线程池任务 `panic`:
    - 使用 `std::panic::catch_unwind`， 这个函数接受一个 `closure`, 然后运行，如果 `closure panic` 了返回 `Err` ，否则返回 `Ok`
    - 线程 `panic` 也会运行数据也会 `drop` 的, 所以可以用这个控制线程数量, 还有个 `thread::panicing` 可以判断线程是否 `panic` 了
    - 还有个方法是重写 `panic-handler`
- 需不需要细分 `Error`
    - 再等等
- 线程池中线程 `panic` 了是 *让其关闭然后重开* 还是 *用 `catch_unwind` 然后继续用*
    - 其实我感觉差别不大，除非频繁 `panic`,后者或许更节俭一点，但前者的优势是 (没错，我还没想到)

### todo-list
- better log
- 服务器端启动时设置 `buffer` 大小的接口
- 非正常退出的索引问题， 思路： 启动时检查， 比较 `index` 和 `log` 文件更新时间， `log` 晚于 `index` 则 `index` 无效。
- 要不要把 `server.rs` 和 `client.rs` 加入到 `bin` 目录下面
- 将 *序列化方式* 抽象出来
- 将 `log-file` 抽象出来， 包括名字, 不要直接像 `name_to_id` 这样粗暴的操作
- 将 *文件* 按 *写入次数* 分割修改成按 *大小*

> *BUG*: `kvstore` 在 `buffer_counter` 不为 1000 时过不了某个测试，
> 原因是我一次压缩一个文件，如果小于1000，就是他写入了1000个，我压缩了小于1000个，还是变大了。。。