现在流行混合云架构，先上图
可能大家看着有点类似12306的
从这个架构图里 ，我们可以把问题 分成 2 个问题来看 ： 1 海量请求的分流 ，2 数据的一致性 和 同步。
乐观松耦合可能需要换一种售票和购票观念。所谓新的售票观念和购票观念，比如预约，预约的方式。BookaTicket。
乐观就是类似乐观锁定的那种方式，比如在12306这个场景上，乐观可以是预定，BookaTicket。
我们现在是买票，买票就是看有没有符合要求的票，有就买，如果有人比你先抢到，那你就后一个买，如果被抢完了，那你就买不到，只能再等。
这种“抢”的方式会造成大量的访问在同一时间拥挤向服务器。
如果是预定的方式，你可以在任何时候做一个预定，系统可以随时受理你的预定，系统受理预定，并不表示现在就购票成功，也不表示未来一定有票，但是系统会在一定的时间结算某一批预定，然后根据票况给予预定的结果。
如果符合你的要求有票，那么系统会回复消息给你“您预定的票已可购买，在1个小时内回复xxx确定购买”。
那么，你在1个小时内回复xxx的话（当然包括了支付钱），那么就购买成功了。
如果没有符合要求的票，或者符合要求的票已经用完了（安排给在你之前预定的人们了），那么系统会回复你“没有符合您的要求的票”或者“符合要求的票已预定完，请再次预定”。
你可以再次预定，然后等待系统通知，如此循环。
如果从架构的角度来解释预定这种业务，可以这样解释，传统的购买相当于同步，预定相当于异步，预定（异步）可以解决同一时间大量请求拥挤向服务器的问题。
同时可以解决数据一致性和同步的问题。
异步可以在一定的时间进行一次“结算”，就不需要像同步方式那样为了数据一致性和数据同步而需要极致的服务器资源和网络资源。
你把需求提给服务器，服务器不是即时（同步）答复，而是，“先考虑一下”，把很多用户的需求都汇集一下，再统一答复一次。
消息队列是“架构”里异步的代表，但在这里说的解决方案中，具体的技术可以是各种各样。
轮询redis，甚至轮询数据库也是可以的么。^^
事实上，用户的需求会先持久化，所以，可能会轮询数据库。
因为是异步乐观松耦合的架构，所以，轮询数据库也是很轻松的，不会给系统造成负担。
我们再看上面的那个架构图，图的下方列出了余票查询集群、用户登录集群、订单分级查询、票价计算集群、实名制身份确认集群5项。
我们可以看到图的中央，红色粗的箭头“海量购票请求”，这个就是来自于全国的用户的购票请求。这个请求是指向“铁路总公司数据中心”。
中央还有一个蓝色的比较细的箭头，是“余票查询请求分流”，指向阿里云公有云数据中心，也就是说，阿里云公有云数据中心可以来分担“余票查询”业务。
而左侧有一个“主数据库”，主数据库的数据来自于18个路局的数据汇总，主数据库同时向铁路总公司数据中心和阿里云数据中心（负责余票查询分流）提供数据（同步数据）。
从这个图的架构中我们可以看到，核心交易是发生在“铁路总公司数据中心”，就是说，这是一个实时的，中心化的数据库支持的业务系统。
同时也可以判定，余票查询不是实时的，是一个参考性的资料。具体能不能买这个票，在真正买票（在铁路总公司数据中心中发生交易）时才能知道结果。而“铁路总公司数据中心”这个中心数据库，它的承载能力来自于一个分布式数据库Gemfire。
京公网安备 11010802035086号