金融数据库TDSQL

tdsql

三层：
网关层： 路由表 + 解析mysql（类似无状态的server）
存储层：真实的mysql，添加agent用以容灾备份数据切换
控制层：zookeeper用以存储状态，加一个keeper用以进行调度

扩容：
水平扩容
垂直扩容

谁扩容
扩容到哪
怎么扩
一般来说 CPU打到了100的话，扩容整张表出去。如果记录太多，分裂扩容后，cache生成唯一key（node的hash）
可以使用QQ号作扩容，使数据均匀

插播一条 mysqlbin
binlog
数据库的二进制文件，记录用户对数据库操作的sql语句
statement：记录所有产生修改的sql。日志数少，减少了磁盘IO，但是可能会造成主从不一致的情况（sleep（）等）

row：记录哪些数据被修改，修改的结果如何。不会出现特定的情况的存储过程，以及触发无法正确复制等问题。但是会产生大量日志，alter table。

混合模式。

通用的扩容方式：
即时扩容，同时将请求转发到目标set，如果记录不存在于目标，则回到源主机请求，随着扩容的持续，源主机压力逐渐减小。
tdsql：
由于关系型数据库，不知道key的话，造成访问混乱。采用分步的措施。先扩容，记录mysqlbin的操作，然后slave进行同步。但是高并发场景下，sql操作是追不上。
所以采用主动失效的方法，重命名原set，然后导致请求失败，同时完成slave的同步。 200ms的失败，对于业务是可以忍受的。

快速失败，能失败则失败。方便数据回滚。
业务容忍度，200ms的无效请求不会对业务造成太严重的影响

屏蔽掉了部分mysql的功能 例如 join。趋势是将数据放入大数据平台hadoop进行后续工作。
类似于epoll

忙轮询
无差别轮询：select poll  O(n)
epoll：epoll pool 只关注缓冲区非满以及缓冲区非空事件

避免一些复杂操作引起的服务器压力剧增。

高一致容灾：
自动切换
自动恢复
数据一致
跨idc容灾
高性能

对于 zookeeper agent 存在心跳连接 超时则按照数据库节点down掉来处理，zookeeper之间同时存在相互的心跳连接。
schedule观测到节点down掉都会启动备机顶替方案，并修改路由。

数据一致性的保障：
类似半同步，master完成事务后将binlog同步到备，然后备同步完成以后返回一个relaylog，master接到应答以后才返回commit到客户端。（牺牲时间换取准确度）
要求：成功则必须一致成功，失败可以回滚。
一主多备的情况下，只需要等待一台完成应答即可，即使一台down掉也没问题。
问题：半同步的io等待造成了性能持续下降 2200 TPS
解决方案：牺牲部分时效性，提高支持效率。异步化改进的半同步方式，防止阻塞，在等待期间将连接保存下来（类似保存一个session），该线程则可以继续处理其他任务。提高到9500.。但是时耗略微增大。自称为 强同步

主备切换：
1 scheduler检测到主节点异常，主降级，如果活着 提供读服务，不能写
2 降级时需要将所有备的 收到的最新的binlog提交，查看谁的更新，则选为主
3 等待最新的更新完成 送到realaylog则 路由请求均到该备机，备升为主
4 如果主还未挂掉，比对当时的binlog，将多出来的写操作 回滚掉，然后作为新的备机

限制：
数据一致性 主动扩容 保证了数据的准确性，但是同时牺牲了很多mysql原本的功能，比如存储 触发 session变量 自增序列号等。但对于金融数据而言，准确性显然更为重要。
不用cache：存储的是结构化数据，sql操作，支持多个索引，很多k-v形式数据不支持索引，高一致性做到了极致，事务均能落地到数据库，更加可靠。虽然性能差了不少，但是相对而言更加符合需求

业务需求：
通过一个shard（标识，用于路由区分）进行切分，所有对某一张表都有这个字段，所有请求都能带上这个字段，否则请求都会到shard上造成很大的负载