海量数据存储
- 分库表基础上，单master多slave横向扩展
- master和slave通过binlog近乎实时同步，任意slave可为master实时备份
- 主业务和辅业务模块数据库分离
- 多地部署，一处写入多出读取，保证就近读取
架构模式
- 分层：横向切分
- 分割：纵向切分
- 分布式：分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案：
- 分布式应用和服务
- 分布式静态资源
- 分布式数据和存储
- 分布式计算
- 分布式配置
- 分布式锁
- 分布式文件
- 集群：多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务
- 缓存：将数据放距离计算最近的位置加快处理速度，改善性能第一手段，可以加快访问速度，减小后端负载压力。使用缓存 两个前提条件 ：1.数据访问热点不均衡；2.数据某时段内有效，不会很快过期
- CDN
- 反向代理
- 本地缓存
- 分布式缓存
- 异步：旨在系统解耦。异步架构是典型的消费者生产者模式，特性如下：
- 提高系统可用性
- 加快网站访问速度
- 消除并发访问高峰
- 冗余：实现高可用。数据库的冷备份和热备份
- 自动化：包括发布过程自动化，自动化代码管理，自动化测试，自动化安全检测，自动化部署，自动化监控，自动化报警，自动化失效转移，自动化失效恢复，自动化降级，自动化分配资源
- 安全：密码，手机校验码，加密，验证码，过滤，风险控制
核心要素
- 性能(Performance)
- 可用性(Availability)
- 伸缩性(Scalability)
- 扩展性(Extensibility)
- 安全性(Security)
CAP
基于水平扩容能力和成本考虑，传统的强一致的解决方案（e.g.单机事务）纷纷被抛弃。其理论依据就是CAP原理，往往为了可用性和分区容错性，忍痛放弃强一致支持，转而追求最终一致性。
- Consistency：强一致性就是在客户端任何时候看到各节点的数据都是一致的（All nodes see the same data at the same time）。
- Availability：高可用性就是在任何时候都可以读写（Reads and writes always succeed）。
- Partition Tolerance：分区容错性是在网络故障、某些节点不能通信的时候系统仍能继续工作（The system continue to operate despite arbitrary message loss or failure of part of the the system）。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
常见代表
- CA：RDMBS
- CP：Redis MongoDB HBase
- AP: CounchDB Cassandra DynamoDB Riak
设计建议
- 减少单点
- 去单点首先要识别整个系统所有主链路的单点，如机房（同城异地双机房），应用服务器，DNS服务器，SFTP服务器，LBS，缓存服务器，数据库，消息服务器，代理服务器和专线等，如系统通过专线调用对方服务，需要考虑同时拉联通和电信的专线，联通或电信的专线还是有一定概率会出现问题的，但是同时出问题的概率会小非常多。优先使用软负载，使用硬负载兜底。
- 减少依赖
- 减少DNS依赖，减少远程服务依赖，DNS依赖可以尝试设置本地host，用工具给所有服务器推送最新的域名映射关系，通过本地缓存或近端服务减少RPC调用。
- 限制循环
- 避免无限死循环，导致CPU利用率百分百，可以设置for循环的最大循环次数，如最大循环1000次。
- 控制流量
- 避免异常流量对应用服务器产生影响，可以对指定服务设置流量限制，如QPS，TPS，QPH（每小时总请求量）和QPD（每天总请求量）。
- 精准监控
- 对CPU利用率，load，内存，带宽，系统调用量，应用错误量，PV，UV和业务量进行监控，避免内存泄露和异常代码对系统产生影响，配置监控一定要精准，如平时内存利用率是50%，监控可以配置成60%进行报警，这样可以提前感知内存泄露问题，避免应用无响应。
- 无状态
- 服务器不能保存用户状态数据，如在集群环境下不能用static变量保存用户数据，不能长时间把用户文件存放在服务器本地。服务器有状态会难以扩容，且出现单点问题。
- 容量规划
- 定期对容量进行评估。如大促前进行压测和容量预估，根据需要进行扩容。
- 功能开关
- 打开和关闭某些功能，比如消息量过大，系统处理不了，把开关打开后直接丢弃消息不处理。上线新功能增加开关，如果有问题关闭新功能。
- 设置超时
- 设置连接超时和读超时设置，不应该太大，如果是内部调用连接超时可以设置成1秒，读超时3秒，外部系统调用连接超时可以设置成3秒，读超时设置成20秒。
- 重试策略
- 当调用外部服务异常时可以设置重试策略，每次重试时间递增，但是需要设置最大重试次数和重试开关，避免对下游系统产生影响。
- 隔离
- 应用隔离，模块隔离，机房隔离和线程池隔离。可以按照优先级，不变和变几个维度来隔离应用和模块，如抽象和不变的代码放在一个模块，这个模块的代码几乎不会修改，可用性高，经常变的业务逻辑放在一个模块里，这样就算有问题，也只会影响到某一个业务。不同的业务使用不同的线程池，避免低优先级任务阻塞高优先级，或高优先级任务过多时影响低优先级任务永远不会执行。
- 异步调用
- 同步调用改成异步调用，解决远程调用故障或调用超时对系统的影响。
- 热点缓存
- 对热点数据进行缓存，降低RPC调用。如B系统提供名单服务，B系统可以提供一个client SDK提供近端缓存服务，定期去服务器端取数据，减少RPC调用。
- 缓存容灾
- 当数据库不可用时可以使用缓存的数据。并设置分级缓存，如优先读本地缓存，其次读分布式缓存。
- 分级缓存
- 优先读本地缓存，其次读分布式缓存。通过推模式更新本地缓存。
- 系统分级
- 对系统进行分级，如ABC三个等级，高级别系统不依赖于低级别系统，并且高级别系统比底级别系统高可用率要高。
- 服务降级
- 如果系统出现响应缓慢等状况，可以关闭部分功能，从而释放系统资源，保证核心服务的正常运行。需要识别哪些服务可以降级，比如突然有大量消息流入，导致服务不可用，我们会把消息直接丢弃掉。或通过设置流控，拒绝为低级别系统提供服务。
- 流量蓄洪
- 当流量陡增时，可以将请求进行蓄洪，如把请求保存在数据库中，再按照指定的QPS进行泄洪，有效的保护下游系统，也保证了服务的可用性。当调用对方系统，对方系统响应缓慢或无响应时，可采取自动蓄洪。
- 服务权重
- 在集群环境中，可自动识别高性能服务，拒绝调用性能低的服务。如在集群环境中，对调用超时的服务器进行权重降低，优先调用权重高的服务器。
- 依赖简化
- 减少系统之间的依赖，比如使用消息驱动，A和B系统通过消息服务器传递数据，A和B系统使用数据库进行读写分离，A系统负责往数据库中写数据，B系统负责读数据，因为数据存放在数据库中，当A不可用时，短时间内不影响B系统提供服务。
- 弹性扩容
- 根据资源的使用率自动或手动进行扩容。如带宽不够用时，快速增加带宽。
- 灰度和回滚
- 发布新功能只让部分服务器生效，且观察几天逐渐切流，如果出现问题只影响部分客户。出现问题快速回滚，或者直接下线灰度的机器。
- 减少远程调用
- 优先调用本地JVM内服务，其次是同机房服务，然后是同城服务，最后是跨城服务。如A调用B，B调用互联网的C系统获取数据，B系统可以把数据缓存起来，并设置数据的保鲜度，减少B对C的依赖。配置中心把注册服务的地址推送到调用服务的系统本地。参数中心把参数配置信息推送到系统的本地内存，而不是让系统去远程服务器获取参数信息。
- 熔断机制
- 增加熔断机制，当监控出线上数据出现大幅跌涨时，及时中断，避免对业务产生更大影响。如我们做指标计算时，指标可以计算慢，但是不能算错，如果发现某个用户的指标环比或同比增长一倍或跌零，会考虑保存所有消息，并中止该用户的指标计算。
- 运行时加载模块
- 我们会把经常变的业务代码变成一个个业务模块，使用Java的ClassLoader在运行时动态加载和卸载模块，当某个模块有问题时候，可以快速修复。
- 代码扫描
- 使用IDEA代码分析等工具进行代码扫描，识别出程序中的BUG，如空指针异常，循环依赖等。
- 自动备份
- 程序，系统配置和数据定期进行备份。可使用linux命令和shell脚本定时执行备份策略，自动进行本地或异地。出现问题时能快速重新部署。
- 线上压测
- 系统的对外服务需要进行压测，知道该服务能承受的QPS和TPS，从而做出相对准确的限流。
架构原则
- 避免过度设计
- 冗余设计
- 多活数据中心
- 无状态设计
- 可回滚
- 可禁用／自我保护
- 问题可追踪
- 可监控
- 故障隔离
- 成熟可控的技术选型
- 梯级存储
- 缓存设计
- 异步设计
- 前瞻性设计
- 水平扩展
- 小步构建和发布
- 自动化