谈谈PhxSQL的设计和实现哲学（上）(3)

PhxSQL由于在同步层使用Paxos,天然支持多数据中心、多机房部署,两地三中心这种部署更是不在话下.对于PhxSQL来说,多数据中心和多机房部署与机房内部署没有区别.PhxSQL的性能取决于多数派机器之间的网络延迟.

5. 为什么要开源?

作为热爱技术的码农,我们相信开源的技术可以使得这个世界更美好.从我们日常开发使用的Emacs/Vim、GCC、GDB,间接为大众提供社交、电子商务、信息服务的Linux、Apache、MySQL、PHP,到大众每日使用来沟通和娱乐的Android等,开源是整个互联网的基石,为全世界提供许多关键不可或缺的基础服务.我们充分享受了开源带来的技术进步、经济发展、和社会前进,我们也希望开源的PhxSQL可以回馈社区,帮助更多有需要的人.

另外,我们希望通过开源更好地改进PhxSQL.我们欢迎技术性讨论和志愿者提交修改.我们承诺开源的PhxSQL会一直更新.除了一些和内部运维支撑系统进行集成的功能(PhxSQL把这些功能抽象成插件,我们针对内部运维支撑系统实现了这些插件),开源版和内部版本将保持一致.

6. PhxSQL的局限性

在一个不完美的世界里,完美是不存在的.我们很坦诚指出PhxSQL存在的两个局限：

6.1. MySQL主机在执行SQL DDL命令(例如建库和建表命令)时可能存在一致性风险.

由于MySQL的innodb引擎不支持DDL回滚,如果主机在innodb已经commit这条DDL命令,但是这条命令的binlog还没到达PhxSQL的拦截点前宕机,则这条DDL binlog会在全局binlog中缺失,从而备机也不会收到这条binlog.而为了保证线性一致性、serializable级别事务隔离、及“最小侵入MySQL”原则,我们也不想修改MySQL源码,提前截获DDL命令.考虑到DDL命令频度较低,我们后续准备在PhxSQLProxy加入检查和后续审计告警.也欢迎大家提出更好方案.

6.2. 在写入请求量很大的系统中,MySQL备机流水可能落后较多；如果这个时候主机死机,备机暂时无法提升成新主机,造成系统在一段时间内不可写.

为了保证线性一致性,对于要求读取最新数据的请求(通过ReadWritePort发起的读请求)也将失败；需要等至少一台备机追完流水,被提升为主机才能响应读取最新数据的请求.对于不需要读取最新数据的请求(通过ReadonlyPort发起的请求),可以从任意备机执行,但不保证线性一致性.(注意：PhxSQL保证无论MySQL主机流水领先MySQL备机多少,MySQL主机binlog流水和全局binlog流水是一致的,不会导致数据丢失和破坏线性一致性.)

MySQL备机追流水落后是基于binlog复制这种模式的一个潜在问题.事实上,不仅MySQL主备,任何一个多副本系统,只要每个写操作不等待所有副本返回,都会出现类似的有些副本落后的问题；而那些等待所有副本返回的模式,在耗时和可用性方面又存在问题.可喜的是MySQL 5.7版本实现了并行复制机制,显著地提高了备机追流水的性能.PhxSQL将很快支持MySQL 5.7,对于写入请求量很大的场景也可以很大程度上避免备机追流水落后的情况.

谈完why,敬请期待《PhxSQL设计和实现哲学》的下章：why not,及与Galera和MySQL Group Replication的比较等.

谢谢阅读!

参考

1. M.P. Herlihy and J. M. Wing. Linearizability: a correctness condition for concurrent objects. ACM Transactions on Programming Languages and Systems (TOPLAS),Volume 12 Issue 3,July 1990,Pages 463-492.

2. L. Lamport. How to make a multiprocessor computer that correctly executes multiprocess programs. IEEE Trans. Computer. C-28,9 (Sept. 1979),690-691.

3. P. Hunt,M. Konar,F. P. Junqueira,and B. Reed. ZooKeeper: wait-free coordination for Internet-scale systems. USENIXATC’10,2010.

4. L. Lamport. Paxos Made Simple. ACM SIGACT News (Distributed Computing Column) 32,4 (Whole Number 121,December 2001) 51-58.

5. D. Ongaro and J. Ousterhout. In search of an understandable consensus algorithm. USENIX ATC ’14,2014.

6. B. M. Oki and B.H. Liskov. Viewstamped replication: a New primary copy method to support highly-available distributed systems. PODC’88,8-17,1988.

7. T. Chandra,R. Griesemer,and J. Redstone. Paxos made live – an engineering perspective. PODC’07,2007.

8. J. C. Corbett,J. Dean,M. Epstein,and etc. Spanner: Google’s Globally-Distributed Database. OSDI’12,2012.

9. F. Pedone,R. Guerraoui,and A. Schiper. The database state machine approach. Journal of Distributed and Parallel Databases and Technology,14:71–98,2002

10. V. Zuikeviciute and F. Pedone. Revisiting the database state machine approach. VLDB Workshop on Design,Implementation,and Deployment of Database Replication. 2005.

11. http://galeracluster.com/documentation-webpages/certificationbasedreplication.html. Visited at 2016/9/5.

12. https://en.wikipedia.org/wiki/Snapshot_isolation. Visited at 2016/9/5.

13. Y. Amir,L. E. Moser,P. M. Melliar-smith,D. A. Agarwal,and P. Ciarfella. The totem single ring ordering and membership protocol. ACM Transactions on Computer Systems. 13 (4): 311–342.

14. http://downloads.mysql.com/presentations/innovation-day-2016/Session_7_MySQL_Group_Replication_for_High_Availability.pdf. Visited at 2016/9/5.

15. http://galeracluster.com/documentation-webpages/architecture.html. Visited at 2016/9/5.

16. http://corosync.github.io/corosync/. Visited at 2016/9/5.

17. http://www.spread.org/. Visited at 2016/9/5.

18. http://galeracluster.com/documentation-webpages/isolationlevels.html. Visited at 2016/9/5

19. L. Lamport. Fast Paxos. Technical Report,MSR-TR-2005-112.

20. I. Moraru,D. G. Andersen,and M. Kaminsky. There is more consensus in egalitarian parliaments. SOSP’13,2013.

21. https://github.com/tencent-wechat/phxpaxos.

22. http://mp.weixin.qq.com/s?__biz=MzI4NDMyNTU2Mw==&mid=2247483783&idx=1&sn=a2d6e589f1f591ded7703eb74aefccbe. Visited at 2016/9/5.

文：mingchen

文章出处：微信后台团队

（编辑：ASP站长网）