zhh-4096
2020-01-08 16:07:35 发布
有时会画一些简单的草图，然后看着它思考，这样直观一些。今天就在盯着这张草图在想怎么优化复制协议和算法。前两个是update和delete发生冲突时如何做（就是检测到行锁冲突了），最后一个是insert没有主键的表，用append在btree那里新增记录时在不同节点得到的rowid不同如何破解（mysql分组复制还不支持这种场景，表要有主键才能用分组复制的功能）。

我突然发现这三种场景也有可能在客户端发出sql语句开始然后收到服务器端的响应，这样经过一个round trip后，在客户端判断出存在冲突或rowid不一致时然后再额外发起一个不影响客户端延迟的异步提交操作完成处理。也就是说，客户端只要在第一个round trip完成后，在客户端那里把冲突识别了，再异步提交到服务器端就可以了，不需要等待这个提交操作发出去就能去干别的事了。

服务器端即便还没有收到提交请求，它也能在后端做跟客户端一样的事。

所以，如果不发生冲突，显然就是正常的情况了，一个round trip就能结束客户端发起的写操作；如果发生冲突了只需要多加一个异步提交的操作就能完成，那么这种复制算法和协议绝对是目前世界上最先进的技术方案了。

我还在思考可能的漏洞，即便有错，这种对等架构下的多节点可写方案配上为不同场景做特殊优化，就是一次头脑解放运动，不必固守在老派的Paxos思想框架里！