《异地多活 IDC 机房架构》由会员分享，可在线阅读，更多相关《异地多活 IDC 机房架构（44页珍藏版）》请在金锄头文库上搜索。
1、荔枝FM架构师 刘耀华异地多活IDC机房架构内容问题与需求系统理论系统调研架构设计最佳实践Q&A问题与需求分析单一机房架构问题 机房不可用时数据无法访问数据安全 机房不可用时业务停止业务可用 性 因网络连通性，不同地域的 用户的请求响应延迟不同用户响应多机房备份保留重要的用户与系统数据，以保证数 据安全提高系统可用性，当某一机房发生故障时 能尽快地切换都另一机房继续提供服务。提高系统访问性能，按用户地域来合理分配 距离最近，访问最佳的机房。系统理论CAP理论University of California, Berkeley computer scientist Eric Brewer,一致性
2、(Consistency)所有节点都能访问同一份最新的数据副本可用性(Availability)每个请求都能接收到一个响应，无论响应成功或失败，而不应该是网络超时、连接断开等非服务程序答复。分区容忍性(Partition tolerance)除了整个网络的故障外，其他的故障（集）都不能导致整个系统无法正确响应。CAP三选二原则CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。AC模型：（可用性+强一致性）-分区容忍MySql Cluster集群Availability: Mysql集群内部分节点失效， 操作仍可执行。Partition: Mysql各节点无法脱离集群独立 工作。
3、Consistence:Mysql提供两阶段提交事务方 式，保证各节点数据强一直性。CP模型：（一致性+分区容忍）-可用性Redis 客户端哈希/Twemproxy集群Availability: 当Redis某节点失效，其节点里 的所有数据都无法访问Partition: 各Redis节点独立服务，互不影响。Consistence: 各Redis节点无共享数据，所以 不存在节点间数据不一致问题。AP模型：（可用性+分区容忍）-强一致性Cassandra集群Availability: 当少于一定数量的节点失效时， 集群服务不受影响。Partition: 数据在多个节点中备份，单个节 点失效不会影响
4、整个集群服务。Consistence: 各节点间的数据非实时强一直性。 只要求数据在部分节点写入成功 后即可，其余节点异步同步。CAP数据库模型互联网行业模型不同的业务类型要求不同的CAP模型：CA适用于支付、交易、票务等业务要求数据强一致性的行业；（宁愿业务不可用，也不能出现脏数据或数据错乱）而互联网则对严格一致性要求不太高，但对业务可用性要求较高。因此一般都采用高可用+分区容忍+弱一致性架构。（+A+P-C）,并衍生出BASE模型。BASE理论eBay的架构师Dan Pritchett源于对大规模分布式系统的实 践总结，在ACM上发表文章提出BASE理论。BASE是指基本可用（Basica
5、lly Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。BASE模型基本可用（Basically Available）基本可用是指分布式系统在出现故障的时候，允许损失部分 可用性，即保证核心可用。服务降级BASE模型软状态（ Soft State）软状态是指允许系统存在中间状态，而该中间状态不会影响 系统整体可用性临时数据不一致。全局锁v.s数据多版本BASE模型最终一致性（ Eventual Consistency）最终一致性，就是不保证在任意时刻任意节点上的同一份 数据都是相同的。但是随着时间的迁移，不同节点上的同一份数据总
6、是在向 趋同的方向变化。数据一致性模型强一致性（串行）线性一致性（时钟同步）序列一致性（全局序列号）因果一致性（关联进程间同步，不相关进程 则最终一致）最终一致性(窗口期数据不一致)最终一致性根据互联网业务特性，最后选择最终一致性。系统业务调研服务器系统当前服务端系统架构App服务Web服务服务总线上传系统业务层主播后台数据中心账号管理审核系统数据层存储层 DataBaseMemCachedRedis接入层连接管理NginxSocket代理分布式文件 系统业务数据分析类型类型数据量数据量优先级优先级主传输线 路主传输线 路后备传输 线路后备传输 线路资源文件资源文件大低公网机房专线数据数据小高
7、机房专线公网架构设计硬件物理架构系统架构数据存储（DataStore）系统数据存储系统DataStore主机房DS服务器失效从机房DS服务器失效脑裂问题运维与监控最佳实践数据切分先纵再横先按业务进行垂直拆分再按ID哈希进行水平拆分按业务拆分按ID哈希拆分数据只改不删记录在数据库中删除后很难恢复尽量做删除标记，而不是物理删除善用异步处理异步响应能提高系统使用效率，避免线程挂起死等。异步会增加编程复杂度，提供简单易用的异步接口所有外部的IO操作都有可能因操作缓慢而阻塞：e.g.写硬 盘复杂逻辑处理用异步提高程序可测试性、可分析性测试驱动，对每个单元写测试用例提交修改后执行回归测试运行时日志统一收集
8、统一监控程序逻辑对一致性的容忍由于架构为最终一致性，程序代码中需容忍一段时间的数 据不一致窗口期。如insert之后马上select刚插入的记录，由于读写分离，有 可能是无法读取刚生成的记录。幂等操作由于网络、机器等不稳定因素，请求有可能会失败。分布式系统的三态：成功、失败、超时。其中超时最难处理，有可能请求包丢了，是服务端没收到；也有可能是服务端已收到并处理了请求，但返回包丢了。如果操作不幂等，客户端收到超时后重试，会导致失败或数据冲突。例如对同一id的记录应采用replace，而不是insert推 v.s 拉直接推送数据比拉取数据请求减少一个消息传递。推送需要区分接收与执行线程记录好接收i
9、d，并在下次重连时重新请求同步做好监控系统资源（CPU、内存、磁盘、网络、文件描述符、IOW）进程监控（错误与警告日志、内存泄露、命令响应速度）存储系统监控（操作量、并发量、慢查询）服务监控（消息拨测、网络拨测、网络连通性）实时报警（邮件、IM、短信）报告（日报、分时曲线、峰值、High/Low watermark）架构要易于随时扩展或缩减当遇到性能瓶颈时，能够方便地迅速扩容调整。对上层业务透明支持热更新（代码、配置、架构）提供一键式操作预案。操作后自动测试验证架构对程序开发友好接口API简单明了与业务解耦减少依赖，或使用依赖管理工具（Maven）配置简单，约定优于配置（COC）原则（Convention Over Configuration）Q&A
