分布式系统数据事务一致性问题

如何解决分布式系统数据事务一致性问题（HBase加Solr） - 王安琪 - 博客园
http://www.cnblogs.com/wgp13x/p/4577181.html

在《淘宝技术这十年》这本书里也提到这么一段描写“用户在银行的网关付钱后，银行需要通知到支付宝，但银行的系统不一定能发出通知；如果通知发出了，不一定能通知到；如果通知到了，不一定不重复通知一遍。这个状况在支付宝持续了很长时间，非常痛苦。支付宝从淘宝剥离出来的时候，淘宝和支付宝之间的通信也面临同样的问题，那是2005年的事情，支付宝的架构师鲁肃提出用MQ（Message Queue）的方式来解决这个问题，我负责淘宝这边读取消息的模块。但我们发现消息数量上来之后，常常造成拥堵，消息的顺序也会出错，在系统挂掉的时候，消息也会丢掉，这样非常不保险。然后鲁肃提出做一个系统框架上的解决方案，把要发出的通知存放到数据库中，如果实时发送失败，再用一个时间程序来周期性地发送这些通知，系统记录下消息的中间状态和时间戳，这样保证消息一定能发出，也一定能通知到，且通知带有时间顺序，这些通知甚至可以实现事务性的操作。”
一致性更是可以分为强一致性和弱一致性两种，弱一致性可以允许某一时间间隔内的偶尔不一致，强一致性的要求要高很多。在实际中，弱一致性往往就能达到业务要求，甚至某些银行系统都只要求弱一致性即可，允许不一致性的窗口存在，只要不造成损失即可。

做个总结：无论是我们设计方案，还是其他类似的分布式系统事务性解决方案，其的本质思想是一样的，即是：做个缓存，先把没确认的存着，等后期有时间了挨个确认。
“既然计算是异步的，那么反馈也应该是异步的，你完全可以让SendMail将发送结果写入数据库，并生成报表，然后让应用程序定期对报告中发送失败的邮件执行再次发送。这里需要假设失败的情况并不是很多。”在《构建高性能web站点》第17章分布式计算-异布计算中对此类问题的解决方法，也是构成我们解决HBase和Solr分布式系统事务一致性问题的重要指导，感谢作者郭欣。当然也感谢《大型网站系统与Java中间件实践》的作者曾宪杰、《构建高性能web站点》的作者郭欣。更感谢分享海狗系统设计的蒋杰（花名：平原君），以及众多乐于分享技术的人们。
看这些书，觉得系统架构方面的技术真的是非常庞大，佩服阿里的那群将数据从小做到大的问题解决者。千里之行，始于足下。