架构
何为架构
架构是为了解决系统软件复杂度问题的；
架构的复杂度来源
高性能
集群的复杂度
1、任务分配
任务分配器；
任务分配器和业务服务器之间存在连接和交互，需要选择合适的连接方式
任务分配器需要增加分配算法
轮询
权重
负载(如何按照负载来分配，那么业务服务器还要能够上报自己的状态给任务分配器)
上面的架构只是对增加一台业务机器，如果我们的QPS、TPS指标有了提高之后，那么我们的任务分配器可能就有多台，业务服务器随之也会增加，这种情况下面临的问题：
任务分配器变成多台；如何将用户分配到某一个任务分配器上；常见的方法包括：DNS轮询、智能DNS、CDN（内容分发网络）、GSLB设备（全局负载均衡）等
任务分配器和业务服务器之间的连接从简单的“一堆多”演变成了“多对多”的网状结构
机器数量也随之增加；状态管理、故障处理复杂度也会大大增加
2、任务分解
为什么需要任务分解？以及任务分解的好处？
简单的系统更容易做到高性能（系统的功能越简单，影响性能的点就越少，就更容易进行有针对性的优化）
可以针对单个任务进行扩展（当把任务分解到子系统的时候，这时候就更加容易发现系统的瓶颈。而且在优化的时候不需要改变整体的架构，风险响应的就会小很多）
任务分解同时也要把握拆分的粒度；
高可用
什么是高可用
系统无中断的执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。
系统做到绝对的“无中断”都是不太可能的事情。因为系统都是运行在硬件和软件之上的，而硬件会老化，软件会越来越复杂和庞大。而且一些自然环境也可以导致系统的中断。
所以，高可用的方案，五花八门。但是万变不离其宗，本质上都是通过【冗余】来实现高可用（就是一台机器不够就上两台，两台机器不够就上四台）。和高性能的解决方案类似，都是通过“冗余”来达到目的。但是其中又有不同之处：
高性能增加机器的目的在于“扩展”处理性能；
高可用增加机器的目的在于“冗余”处理单元。
1、计算高可用
高可用复杂度的体现，在以下几个方面：
需要增加任务分配器
任务分配器和业务服务器之间有连接和交互
任务分配器增加分配算法。如，常见的双机算法有：主备、主主；主备方案又可以细分为：温备、热备、冷备。
当高可用升级为集群的时候，分配算法更加复杂，可以是1主3备、2主2备、3主1备、四主0备，具体采用哪种，还是要根据业务的实际情况来分析和判断。
zookeeper采用的是1主多备
Memchaced采用的是全主0备
2、存储高可用
存储高可用的难点不在于如何备份数据，而是在于如何减少或者规避数据不一致对业务的影响。
CAP定理：一致性、可用性、分区容错性；只能满足其中两个。
3、高可用决策状态
独裁式：指存在一个独立的决策主体，负责收集信息然后决策；
协商式：两个个体通过交流信息，根据规则进行决策；最常用的协商式决策就是主备决策；
民主式：多个独立的个体通过投票的方式进行决策；zookeeper集群选举leader时就是采用的这种方式。