高可用思路：
方法论上，高可用是通过冗余+自动故障转移来实现的。
整个互联网分层系统架构的高可用，又是通过每一层的冗余+自动故障转移来综合实现的，具体的：
（1）【客户端层】到【反向代理层】的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived + virtual IP自动故障转移
（2）【反向代理层】到【站点层】的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移
（3）【站点层】到【服务层】的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移
（4）【服务层】到【缓存层】的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性
（5）【服务层】到【数据库“读”】的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移
（6）【服务层】到【数据库“写”】的高可用，是通过写库的冗余实现的，常见实践是keepalived + virtual IP自动故障转移
高并发：
高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。
提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。
互联网分层架构中，各层次水平扩展的实践又有所不同：
（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；
（2）站点层可以通过nginx来进行水平扩展；
（3）服务层可以通过服务连接池来进行水平扩展；
（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；
各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限
电商数据库并发设计：
业务初期用单库
读压力大，读高可用，用分组
数据量大，写线性扩容，用分片
属性短，访问频度高的属性，垂直拆分到一起
分片当中的分库分表:
假设将原来的单库单表order拆分成256个库，每个库包含1024个表，
那么，按照前面所提到的路由策略，对于userid=262145的访问，
路由的计算过程如下：
中间变量=262145%(256*1024)=1
库=取整(1/1024)=0
表=1%1024=1
这意味着，对于userid=262145的订单记录的查询和修改，将被路
由到第0个库的第1个表中执行
