Knight's Blog
滴滴海浪技术主管, 前百度资深研发工程师,现居上海。 擅长于大规模的系统平台服务架构。在

- 亿级别搜索平台(sov5.com)
- 大规模分布式爬虫
- 中间件架设(disconf,CanalX)
- 广告平台(百度联盟广告)
- 租车平台(滴滴租车)
- 语言招聘平台(51tra.com)
- 内容平台(100weidu.com)
- 社区平台(python88.com)
- 资源下载平台(misou.com)
- 计算机图形图像技术(一篇一作)
- 机器学习(一篇一作)

等领域具有颇有经验。
联系方式: knightliao AT gmail.com
联系
Knight's Blog » 工作

经典的RPC事务均无法达到完全事务一致性

2015-02-10 16:40

经典的RPC事务均无法达到完全事务一致性。

Flume是apache官方提供的一套分布式日志收集工具。在 https://flume.apache.org/FlumeDeveloperGuide.html 这里讲述了如何 实现从一个agnet往另一个agent发消息数据,达到事务一致性。

例如 agent1 调用 agent2,在agent1和agent2那边均开启了事务来保证双方共同事务的一致性。

在这种过程中,会出生几种问题:

  • 1.Agent1调用agent2后,agent2在返回时,连接断开
  • 2.agent1调用agent2后,agent2处理非常慢,一直不给返回
  • 3.agent1调用agent2后,agent2也成功返回了,并且,agent2的事务提交了。在agent1在提交事务前,agent1挂机。

对于第1种情况,agent1表现为连接断开,此时双方自行回溯数据即可。

对于第2种情况,agent1表现为连接超时,此时只要保证agent2的超时时间小于agent1的超时时间 即可以保证数据一致性。

对于第3种情况(当然这种情况发生的机率很小,可以通过safe close方式来避免此问题),agent2成功了,但是agent1失败了。此时没有有效的办法,让agent2去回滚。在这种情况下,经典的RPC事务无法达成一致性

一种常用的解决办法就是用补偿机制,agent1有持久化策略,在agent1再次启动时,将失败的消息再次发送给agent2,此时agent2会得到两条一样的数据。这时需要一些业务情况来保证。

http://flume.apache.org/_images/DevGuide_image00.png

https://flume.apache.org/_images/DevGuide_image01.png

2863 次点击