上一篇文章咱们聊了聊TCC分布式事务，对于常见的微服务系统，大部分接口调用是同步的，也就是一个服务直接调用另外一个服务的接口。 这个时候，用TCC分布式事务方案来保证各个接口的调用，要么一起成功，要么一起回滚，是比较合适的。 但是在实际系统的开发过程中，可能服务间的调用是异步的…

上篇文章（《亿级流量系统架构之如何设计每秒十万查询的高并发架构》），聊了一下系统架构中的查询平台。 热数据基于缓存集群+MySQL集群做到了当日数据的几十毫秒级别的查询性能。 最终，整套查询架构抗住每秒10万的并发查询请求，都没问题。 本文作为这个架构演进系列的最后一篇文章，我…

这篇文章，我们来聊聊在线上生产环境使用消息中间件技术的时候，从前到后的全链路到底如何保证数据不能丢失。 这个问题，在互联网公司面试的时候高频出现，而且也是非常现实的生产环境问题。 如果你的简历中写了自己熟悉MQ技术（RabbitMQ、RocketMQ、Kafka），而且在项目里…

相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 是个什么东西吗？如果别人/面试官让你给他讲讲 ZooKeeper 是个什么东西，你能回答到什么地步呢？ 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心，另外在搭建 solr 集…

距离上一次写Spring源码解析，已经过去了快要好几个月了，主要原因还是Spring的源码解析类文章太难写了，不像我先前写的什么CAS源码，AQS源码，LinkedBlockingQueue等等，这些无非就是分析几个核心方法，代码也不算太长，就像比较复杂的AQS源码也是两篇搞定…

随着分布式服务架构的流行与普及，原来在单体应用中执行的多个逻辑操作，现在被拆分成了多个服务之间的远程调用。虽然服务化为我们的系统带来了水平伸缩的能力，然而随之而来挑战就是分布式事务问题，多个服务之间使用自己单独维护的数据库，它们彼此之间不在同一个事务中，假如A执行成功了，B执行…

在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的 ACID 特性，需要引入一个作为协调者的组件来统一掌控所有节点 (称作参与者) 的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。 (from Wikipedia)

正好这位同学面试前学习了笔者之前出的一套Java面试突击教程，里面就涉及到了关于缓存的一些问题。 这篇文章，是这位同学对自己阿里一面的总结，大家可以参考一下，同时也感谢乔二爷同学的分享。 昨天晚上接到阿里的电面电话，过程中就问到了关于缓存相关的问题。 虽然以前接触过，多多少少了…