最近不那么忙了，于是希望对业界的系统进行比较深入的了解．恰好TiDB也开放了相当数量的blog，以及对开发者还比较友好，于是就从TiDB开始，记录一下现代系统的一角以及工业界可能偏好的解决方案．
这篇讲了TiDB = tidb-server/pd-server/tikv-server．提到mock-tikv 的组件利用本地存储模拟 tikv-server 的行为，特别是 Coprocessor 模块的逻辑
这篇讲了TIDB storage = RocksDB（单机） + sorted region(不是哈希，会有balance）+ raft + MVCC(避免分布式锁）+ TXN OCC(percolator)
所以做一个现代的系统解决方案是尽可能reuse别人的东西，单机kernel挺难的，割给rocksdb了. 存储层的raft优化，他们提供了一些优化细节．然后txn的事情，不用2PL，而使用了适合分布式的乐观锁OCC（就是没有锁）．但OCC三阶段其中要查r/w sets在分布式场景下也不容易．
这篇讲TiDB compute layer = stateless server(load balance) + key mapping
怎么由key搜到具体的值，单机数据库是建B+ tree，指向page id+row id, 或者走LSM，在sorted keys中做查询. 看起来TiDB并非LSM, 却用了全局sorted keys（以及前面提到的regions).这里的index不直接指向page id，而是rowid，而恰恰好TiDB是sorted regions分布，定位到单个机器之后，底层丢给rocksDB．狡猾狡猾的．
这里的key, 普通值被映射到这个，注意这里是row oriented（说好的newsql呢哈哈）．而index单独做映射，rowID放在key里而不算value里，为了处理duplicate keys
Key： tablePrefix_rowPrefix_tableID_rowIDValue: [col1, col2, col3, col4Key: tablePrefix_idxPrefix_tableID_indexID_ColumnsValue_rowIDValue：null
注意这种key encoding方式可以使前后的顺序一致（原文称保证编码前和编码后的比较关系不变），有些clustered的意味．方便分块读取．
Metadata/catalog也是映射成某种key存．提了一下异步schema变更
另外为了加速计算，主要考虑是减少rpc次数，简单说就是下推计算...（减少对kv server的调用次数，争取一次调用干更多事情嘛）rocksdb表示好无奈啊，为啥宝宝还要干这么多．
PD（Placement Driver）= 全局metadata管理＋load balance
算是考虑raft在内的负载均衡吧，本质还是负载均衡算法，就是麻烦一点
这篇讲了一些相对具体的考虑：
作为一个分布式高可用存储系统，必须满足的需求，包括四种：
- 副本数量不能多也不能少
- 副本需要分布在不同的机器上
- 新加节点后，可以将其他节点上的副本迁移过来
- 节点下线后，需要将该节点的数据迁移走
作为一个良好的分布式系统，需要优化的地方，包括：
- 维持整个集群的 Leader 分布均匀
- 维持每个节点的储存容量均匀
- 维持访问热点分布均匀
- 控制 Balance 的速度，避免影响在线服务
- 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点
不过我对调度没有兴趣．调度是我本科时候学校lab最喜欢搞的东西，因为可以抽象出来各种参数，套各种先进算法．虽然调度很重要，paper满天飞，vmware, aws都靠这个赚大钱，我反正已经反胃了
材料队列：
TiDB MVCC．初看了一下，是timestamp ordering的实现
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31537575/viewspace-3118833/ ，如需转载，请注明出处，否则将追究法律责任。
