谈谈PhxSQL的设计和实现哲学（下）

在一个典型的两地三中心部署中,这导致一次事务写操作延迟极其高昂.例如一地两中心的网络延迟一般可以控制在2ms(单向),上海－深圳间网络延迟一般是15ms(单向),则一次事务写操作的网络延迟是64ms!在两地三中心的配置中,PhxSQL的主和一个备一般分别在一地的两中心,另一个在异地.在通常情况下,master的Paxos一次写入只需一个accept,并且只等最快的备机返回.这时PhxSQL的写延迟只有4ms!

相比Paxos这类协议,原子广播还有一个缺陷.当任意一台机器宕机或者网络中断时,Totem此时会超时,在踢掉宕机的机器、重新确定组成员之前,整个集群的消息停止执行,即写操作暂停.

对于read-only事务,只有去数据集合的主机读取、或者昂贵地读取原子广播Quorum台机器、或者使用类似Spanner的TrueTime[8]技术读取任一符合资格的机器,才能保证线性一致性.Galera节点间有延迟,并且只读事务在本地执行,不支持线性一致性[15].如果MySQL Group Replication支持线性一致性,请不吝告知.

了解基于原子广播的组内多主多写模式的原理和优缺点后,使用多写模式还需要根据业务仔细划分数据集,尽量减少公共数据的使用,同时处理好自增key的细节问题,以减少事务间的跨机冲突.

PhxSQL建立在开源的PhxPaxos基础上,感兴趣的读者可以用PhxPaxos方便实现原子广播插件,加载到MySQL中,从而支持多写.

如果不要read repeatable或者serializable级别隔离的事务,例如简单的key-value操作,同时通过lease机制保证线性一致性,是可以做到高效率多写的.但这就违反了PhxSQL完全兼容MySQL和最小侵入MySQL的原则.

7.2. 为什么不支持分库分表?

分库分表也是个诱人的选择：可以平行无限扩展读写性能.分库分表就是分组,上个小节已经讨论了分布式事务的高昂成本.另外,为了保证完全兼容MySQL、支持全局事务和serializable级别事务隔离,不大改MySQL就支持sharding是非常困难的.大改又违反了“最小侵入MySQL”原则,并且可能引入新的不兼容性.在应用不要求全局事务和serializable级别事务隔离情况下,感兴趣的读者可以把PhxSQL作为一容错的MySQL模块,在上层构建支持分库分表的系统.因为PhxSQL本身的容错性,这样做比在MySQL基础上直接构建要简单,无需关心每个sharding本身的出错.如果以后有需求,PhxSQL团队也可能基于PhxSQL开发一个分库分表的新产品.当然,这个产品难以提供PhxSQL级别的兼容性.

7.3. 为什么这么纠结于serializable级别事务隔离性,read repeatable级别很多时候已经够用了啊?

我们在设计原则中已经提到,为了完全兼容MySQL.我们认为一项好的技术是一项简单方便用户的技术,提供符合用户直觉预期、不用看太多注意事项的技术是我们的体贴.我们很诚恳,也是为了方便用户.我们不想说PhxSQL完全兼容MySQL,然后在不起眼的地方blabla列出好几页蝇头小字的例外.事实上,对于关键业务来说,serializable是必要的、read repeatable是不足的.read repeatable有个令人讨厌的write-skew异常[12].

举个例子.小薇在一个银行有两张信用卡,分别是A和B.银行给这两张卡总的信用额度是2000,即A透支的额度和B透支的额度相加必须不大于2000：A+B<=2000.

两个账户的扣款函数用事务执行分别是：

A账户扣款函数：

sub_A(amount_a):

begin transaction

if (A+B+amount_a <= 2000)

{ A += amount_a }

Commit

B账户扣款函数：

sub_B(amount_b):

begin transaction

if (A+B+amount_b <= 2000)

{ B += amount_b }

commit

假定现在A==1000,B==500.如果小薇是个黑客,同时用A账户消费300和B账户消费300,即amount_a == 400,amount_b == 300.那么这个数据库会发生什么事情呢?

如果是read repeatable级别隔离,sub_a和sub_b都会同时成功!最后A和B账户的透支额分别是A=1000+400=1400,B=500+300=800,总的透支额A+B=1400+800=2200>2000,超过了银行授予的额度!如果不是信用卡的两笔小消费,而是两笔大额转账,那么银行怎么办?

如果是serializable级别隔离,则sub_a和sub_b只有一个成功.具体分析有兴趣的读者可以自己完成.

7.4. 为什么不把显著提升MySQL性能作为一个主要目标?

事实上,PhxSQL已经显著提升了MySQL主备的写入性能.与semi-sync比,在测试环境中,PhxSQL的写入性能比semi-sync高15%到20%以上.读性能持平.这是在满足完全兼容MySQL和最小侵入MySQL原则下所能获得的结果.鉴于PhxSQL对MySQL的改动是如此之小,对性能有高要求的读者,可以方便地把PhxSQL中的MySQL换成其它高性能版本,获得更高性能.

7.5. 为什么编译时不支持C++11以下标准?

作为热爱新技术的码农,我们真的很喜欢C++11中期待已久、激动人心的新特性,例如极大增强的模板、lambda表达式、右值和move表达式、多线程内存模型等,这将C++带入了一个新的时代,大大提高了码农搬砖的速度、编码的正确性、和程序的性能.有了C++11,PhxSQL的开发效率提高了很多.

8. 与Galera及MySQL Group replication的比较

参见7.1.2小节.

结论

PhxSQL是一个完全兼容MySQL,提供与Zookeeper相同强一致性和可用性的MySQL集群.

感谢大家看完这么长的一篇文章.希望大家多阅读PhxSQL源码,多提技术性意见,甚至成为源码贡献者!

参考

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

文章出处：微信后台团队

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!