分布式系统中的几个理论

前一段时间一个朋友说了去快手面试的经历，背景应该是让做一个秒杀场景的系统设计。

朋友当然说了类似于“没有明确场景的架构设计都是耍流氓”，朋友的回答围绕于流量漏斗、最终一致去回答，但面试官核心要求是100w tps打到了数据库上你怎么解？

这个事情就很难搞，首先100w tps怎么来的？既然这么多流量都是真实流量，有状态服务和存储服务不具备足够的容量可以支撑吗？肯定要加机器。具体怎么解决流量过滤和数据一致肯定需要看具体场景，比如不同领域下的服务对于数据一致性容忍程度是不一样的，背后肯定方案也不一样。脱离业务场景谈架构果然是耍流氓，最后这个面试是不欢而散。

做秒杀架构主要解决两件事情，一个是高流量，一个是数据一致性。这两个方向问题回答好了，理论上就没有问题了。我自己做面试官心里当然想候选人给我一个完备的方案，但是我也知道在有限的时间、有限的场景下，光靠嘴聊是很难聊得完备的，所以我一般观察两点。

一个是普世方的法论，就是有些事情是永远做不到完美的，也不要期望做到完美，但是你需要告诉我为什么做不到完美，他的本质是什么，怎么做到趋于完美。

第二个是看方案的完备性，什么意思呢？是希望候选人可以给出这个核心问题之外的一些考虑，我个人理解是一种扩展性的体现，提供软状态、最终一致性。

BA（基本可用）：在分布式系统出现故障时，允许损失部分可用性，保障核心可用，比如电商双十一时，为满足商品购买链路的稳定性，可以降级掉用户修改地址这些功能。

S（软状态）：允许系统之间出现中间状态，什么意思呢？不是简单的刚性成功 or 失败，而是在分布式系统下多副本中出现中间状态，这种中间状态是由于多个副本复制延迟导致的，比如mysql replication异步复制。

E（最终一致性）：指的是系统中所有副本数据经过一定时间之后，可以达到最终一致的状态。

ACID原则：

概念包括： 原子性：每次操作是原子的，要么成功，要么失败； 一致性：是强一致性，没有中间状态； 隔离性：各个操作彼此隔离，互不影响； 持久性：数据状态一旦提交，是持久的，不会失效；

ACID一般用于关系数据库的事务定义，追求的是强一致性；BASE是在分布式系统下，牺牲掉对于一致性的约束，以最终一致性的方式提供一致性，换取性能和可用性；两种方案是完全相反的设计哲学，具体怎么用就需要看场景了。

所以架构是取舍的艺术，脱离场景谈架构都是耍流氓，先基于场景，画一个框，在框内找到一个确定性的问题，找到这个问题的本质，给出合适的解。

其他分布式原理，详见：