分布式事务：不过是在一致性、吞吐量和复杂度之间，做一个选择
Sagas给我的感觉式过于复杂，要提供正反操作，这个是个很大的挑战；事件驱动的实现方式，是目前的流行方式；传统的方式比如Java EE中的JTA等，由于事务内部的等待，对于性能影响比较大，不太适合高并发与高性能的场景。
分库分表的几种常见形式以及可能遇到的难题
总结了分库分表的方式。
Tomcat单点登录配置及源码分析
Tomcat中的单点登录
在SingleSignOn中，会先进行userPrincipal的判断，不为空就会直接向后执行，为空时，判断请求中是否包含SSO Cookie。
深度长文：我对CQRS/EventSourcing架构的思考
EDA和CQRS
微服务架构和CQRS架构的关系：每个微服务内部，我们可以用CQRS/ES架构来实现，也可以用传统三次架构来实现。
事件驱动架构的核心思想是：
- 不同于SOA架构，EDA架构是pub-sub模式；Node1处理完逻辑后产生消息，Node2订阅消息并进行处理，Node1不知道Node2的存在；
- 最终一致性原则，Node1，Node2之间的数据一致性通过MQ最终保证一致；
- 如何保证最终一致性（消息链不会断开）：
A. MQ保证消息不丢；
B. 任何一个Node要保证自己完全处理完后才发送ACK给MQ；
C. 每个Node做到对任何消息处理的幂等性； - 整个架构具有所有分布式MQ所带来的优点：如异步解耦、削峰、降低整个系统的整体部署成本；
CQRS本身只是一个读写分离的思想，全称是：Command Query Responsibility Segregation，即命令查询职责分离。一个命令表示一种意图，表示命令系统做什么修改，命令的执行结果通常不需要返回；一个查询表示向系统查询数据并返回。另外一个重要的概念就是事件，事件表示领域中的聚合根的状态发生变化后产生的事件，基本对应DDD中的领域事件；
CQRS架构的核心出发点是将整个系统的架构分割为读和写两部分，从而方便我们对读写两端进行分开优化；
CQRS架构的一致性模型为最终一致性。
采用CQRS架构的一个前提是，你的系统要接受系统使用者查询到的数据可能不是最新的，而是有几个毫秒的延迟。之所以会有这个前提，是因为CQRS架构考虑到，作为一个多用户同时访问的互联网应用，当在高并发修改数据的情况下，比如秒杀、12306购票等场景，用户UI上看到的数据总是旧的。比如你秒杀时提交订单前看到库存还大于0，但是当你提交订单时，系统提示你宝贝卖完了。这个就说明，在这种高并发修改同一资源的情况下，任何人看到的数据总是Stale的，即旧的。
美团外卖订单中心的演进
美团的订单系统。
订单流程图
系统拆分主要有如下几个原则：
- 相关业务拆分独立系统；
- 优先级一致的业务拆分独立系统；
- 拆分系统包括业务服务和数据。
基于以上原则，我们将订单系统进行独立拆分，所有订单服务通过RPC接口提供给外部使用。订单系统内部，我们将功能按优先级拆分为不同子系统，避免相互影响。订单系统通过MQ（队列）消息，通知外部订单状态变更。
网友评论