业界异地多活高可用架构设计方案总结 业界异地多活高可用架构设计方案总结异地多活 在近年越来越多大型互联网公司采用的方案， 几乎也是大型应用发展到一定阶段的必然选择 ，综合比较一下各个互联网公司的方案，会发现有很多共性的东西，也有很多差异化的东西，这是最有意思的地方什么是异地多活异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。冷备份的主要问题是成本高，不跑业务，当主机房出问题的时候，也不一定能成功把业务接管过来。CAP原则分布式架构设计无论怎样都绕不开CAP原则，C一致性 A可用性 P分区容错性，分区容错性是必不可少的，没有分区容错性就相当于退化成了单机系统，所以实际上架构设计是在一致性和可用性一个天平上的两端做衡量。为什么强一致性和高可用性是不能同时满足？假如需要满足强一致性，就需要写入一条数据的时候，扩散到分布式系统里面的每一台机器，每一台机器都回复ACK确认后再给客户端确认，这就是强一致性。如果集群任何一台机器故障了，都回滚数据，对客户端返回失败，因此影响了可用性。如果只满足高可用性，任何一台机器写入成功都返回成功，那么有可能中途因为网络抖动或者其他原因造成了数据不同步，部分客户端独到的仍然是旧数据，因此，无法满足强一致性。异地多活的挑战延迟 异地多活面临的主要挑战是网络延迟，以北京到上海 1468 公里，即使是光速传输，一个来回也需要接近10ms，在实际测试的过程中，发现上海到北京的网络延迟，一般是 30 ms。一致性 用户在任何一个机房写入的数据，是否能在任何一个机房读取的时候返回的值是一致性的。误区所有业务都要异地多活以用户中心为例，注册是没必要做异地多活的，假如用户在A机房注册了，在数据没有向外同步的时候，A机房网络中断，这个时候如果让用户切换到B机房注册，就有可能发生数据不一致，出现两个基本相同的账号，这是不可容忍的。但是相对应的来说，用户登录这种是关键核心业务，就有必要做到异地多活了，用户在A机房登录不了，那就让用户在B机房登录。虽然有极端的情况，用户在A机房修改了密码，但是出现网络中断，B机房的用户仍然保存的是旧密码，但是相对于不可登录来说，这种情况是可容忍的。同时有些业务仍然是无法实现异地多活的，比如涉及到金钱的业务，加入有一个用户有100块，消费了50块，A机房发生异常，数据没有同步出去，这时候用户在B机房登录后发现自己还有100块，可以继续消费，就会对业务造成严重的影响。必须做到实时一致性受限于物理条件，跨地域的网速一定会存在延迟，一般是几十毫秒，如果遇上网络抖动，延迟超过几秒甚至几十秒都有可能。解决方法只能是减少需要同步的数据和只保证数据的最终一致性，有时候用户在A机房修改了一条数据，业务上实际上是能容忍数据的短时间不一致的，即使其他用户在B机房读到的是旧数据，实际上对业务也没有任何影响。只使用存储系统的同步功能大部分场景下，MySQL Redis自带的同步功能已经足以满足需求了，但是在某些极端情况下，可能就不合适了，MySQL的单线程复制可能会产生较大的延迟，Redis可能会有全量复制，所以系统要灵活使用各种解决方案。用消息队列把数据广播到各个数据中心回源读取，当A机房发现没有这条数据的时候，根据路由规则去B机房去读取该数据重新生成数据，A机房登录后生成session数据，这时候A机房挂了，可以把用户切换到B机房，重新生成session数据。实现100%的高可用100%的高可用是无法保证的，硬件的损坏，软件的BUG，光纤传输等太多不可控的因素，而且也要在成本上做一个权衡，尤其是对于强一致性业务，C和A只能取一个平衡，容忍短时间的不可用来保证数据的完全一致性。饿了么异地多活方案特点业务内聚，单个订单的所有流程保证在一个机房内完成调用，不允许进行跨机房调用。每一个机房称为一个ezone，对服务进行分区，让用户，商户，骑手按照规则聚合到一个ezone内。根据业务特点，饿了么选择了把地理位置作为划分业务的单元，以行政省界用围栏把全国分为多个shard。在某个机房出现问题的时候，也可以按照地理位置把用户，商户，骑手打包迁移到别的机房即可。可用性优先，当机房发生故障的时候，优先保证可用，用户可以先下单吃饭，有限时间窗口内的数据不一致可以事后再修复。每个 ezone 都会有全量的业务数据，当一个 ezone 失效后，其他的 ezone 可以接管用户。用户在一个ezone的下单数据，会实时的复制到其他ezone。保证数据的正确性，在切换和故障时，检测到某些订单在两个机房不一致，会锁定改订单，避免错误进一步扩散。通过DRC复制MySQL数据MySQL的数据量最大，每个机房产生的数据，都通过 DRC 复制到其他 ezone，每个ezone的主键取值空间是ezoneid + 固定步长，所以产生的 id 各不相同，数据复制到一起后不会发生主键冲突。按照分区规则，正常情况下，每个 ezone 只会写入自己的数据，但万一出现异常，2个 ezone 同时更新了同一笔数据，就会产生冲突。DRC 支持基于时间戳的冲突解决方案，当一笔数据在两个机房同时被修改时，最后修改的数据会被保留，老的数据会被覆盖。通过Global Zone保证强一致性对于个别一致性要求很高的应用，我们提供了一种强一致的方案（Global Zone），Globa Zone是一种跨机房的读写分离机制，所有的写操作被定向到一个 Master 机房进行，以保证一致性，读操作可以在每个机房的 Slave库执行，也可以 bind 到 Master 机房进行，这一切都基于我们的数据库访问层（DAL）完成，业务基本无感知。新浪微博异地多活方案微博使用了基于 MCQ（微博自研的消息队列）的跨机房消息同步方案，并开发出跨机房消息同步组件 WMB（Weibo Message Broker）。每个机房的缓存是完全独立的，由每个机房的 Processor（专门负责消息处理的程序，类 Storm）根据收到的消息进行缓存更新。由于消息不会重复分发，而且信息完备，所以 MytriggerQ 方案存在的缓存更新脏数据问题就解决了。而当缓存不存在时，会穿透到 MySQL 从库，然后进行回种。可能出现的问题是，缓存穿透，但是 MySQL 从库如果此时出现延迟，这样就会把脏数据种到缓存中。解决方案是做一个延时 10 分钟的消息队列，然后由一个处理程序来根据这个消息做数据的重新载入。一般从库延时时间不超过 10 分钟，而 10 分钟内的脏数据在微博的业务场景下也是可以接受的。由于微博对数据库不是强依赖，加上数据库双写的维护成本过大，选择的方案是数据库通过主从同步的方式进行。这套方案可能的缺点是如果主从同步慢，并且缓存穿透，这时可能会出现脏数据。这种同步方式已运行了三年，整体上非常稳定，没有发生因为数据同步而导致的服务故障。阿里异地多活方案阿里在部署异地多活的时候同样是碰到延时问题，解决方案是访问一次页面的操作都在本机房完成，不做跨机房调用。阿里把业务划分成各种单元，如交易单元，这个单元是完成交易业务，称之为单元化。服务延时让操作全部在同一中心内完成，单元化比如用户进入以后，比如说在淘宝上看商品，浏览商品，搜索、下单、放进购物车等等操作，还包括写数据库，就都是在所进入的那个数据中心中完成的，而不需要跨数据中心部署：异地部署的是流量会爆发式增长的，流量很大的那部分。流量小的，用的不多的，不用异地部署。其他一些功能就会缺失，所以我们在异地部署的并非全站，而是一组业务，这组业务就成为单元比如：在异地只部署跟买家交易相关的核心业务，确保一个买家在淘宝上浏览商品，一直到买完东西的全过程都可以完成路由一致性：买家相关的数据在写的时候，一定是要写在那个单元里。要保障这个用户从进来一直到访问服务，到访问数据库，全链路的路由规则都是完全一致的。如果说某个用户本来应该进A城市的数据中心，但是却因为路由错误，进入了B城市，那看到的数据就是错的了。造成的结果，可能是用户看到的购买列表是空的，这是不能接受的。延时：异地部署，我们需要同步卖家的数据、商品的数据。能接受的延时必须要做到一秒内，即在全国的范围内，都必须做到一秒内把数据同步完中心之间骨干网。数据一致性：把用户操作封闭在一个单元内完成，最关键的是数据。在某个点，必须确保单行的数据在一个地方写，绝对不能在多个地方写。为了做到这一点，必须确定数据的维度。淘宝除了用户本身的信息以外，还会看到所有商品的数据、所有卖家的数据，面对的是买家、卖家和商品三个维度。因为异地的是买家的核心链路，所以选择买家这个维度。按买家维度来切分数据。但因为有三个维度的数据，当操作卖家、商品数据时，就无法封闭。在所有的异地多活项目中，最重要的是保障某个点写进去的数据一定是正确的。这是最大的挑战，也是我们在设计整个方案中的第一原则。业务这一层出故障我们都可以接受，但是不能接受数据故障。多个单元之间一定会有数据同步。一方面，每个单元都需要卖家的数据、商品的数据；另一方面，我们的单元不是全量业务，那一定会有业务需要这个单元，比如说买家在这个单元下了一笔定单，而其他业务有可能也是需要这笔数据，否则可能操作不了，所以需要同步该数据。所以怎样确保每个单元之间的商品、卖家的数据是一致的，然后买家数据中心和单元是一致的，这是非常关键的。总结各种方案都是针对不同的业务场景设计的，所以会有一定的不同，但是基本思路都是一致的。通过各种手段避免进行跨机房调用，消除延迟，让用户无感知。必要的时候通过业务的妥协，牺牲一致性来获取更高的可用性和更低的部署复杂程度。细读CAP理论就知道，这个问题是不存在完美的解决方案的，只有尽量贴合业务，逐渐迭代出更合适的方案。引用：异地多活设计辣么难？其实是你想多了！饿了么异地多活技术实现（一）总体介绍微博“异地多活”部署经验谈绝对干货:解密阿里巴巴“异地多活”技术阿里和微博的异地多活方案zt

集成平台的高可用-双机冷备和热备 集成平台的高可用-双机冷备和热备随着电子病历和互联互通成熟度等级评测的快速推广、集成平台所集成的系统越来越多，作为集成平台基础核心组件的集成引擎的容灾功能越发重要， 宕机而产生的连带后果不容小觑 。其实早在2011年，原卫生部就已经强调落实国家信息安全等级保护制度，三级甲等医院的核心业务信息系统安全保护等级不得低于三级， 保证系统的高可用性。医院集成平台高可用性（HA）的解决方案：双机冷备两个服务器，一台运行，一台不运行做为备份。这样一旦运行的服务器宕机，就把备份的服务器运行起来。 冷备的方案比较容易实现，但 冷备的缺点是主机出现故障时备机不会自动接管，需手动启动硬件和服务。宕机可能无法及时被发现，经常是在数据不到位时才发现服务已经停止，然后手动启动 ，而很多情况下都是直接重启主机来解决，备机有时形同虚设。 冷备容灾部署示意图有些医院在冷备的基础上增加了操作系统层级的热备或使用硬件实现热备, 但这些“热备”都只是在整个服务器宕机的情况下才能触发，而实际经常发生的情况通常是集成平台的服务停止了，但服务器还在运行，这样就不会自动切换到备机，仍然需要手动重启来解决。 因此，集成引擎应用/服务级别的热备就显得非常重要，在主机的服务出现问题时快速自动切换到备机，确保医院的业务继续平稳运行。双机热备双机热备即是通常所说的 active/standby 方式， 服务器数据包括数据库数据同时往两台或多台服务器写。当active服务器出现故障的时候，通过软件诊测（一般是通过心跳诊断）将standby机器激活，保证应用在短时间内完全恢复正常使用。当一台服务器宕机后，自动切换到另一台备用机使用，不需要工作人员手动去切换。 双负载均衡热备容灾部署示意图关于Odin多功能引擎Odin多功能引擎具有双机热备功能 ，符合国家三级等保要求。Odin的高可用性通过消除单点故障，进行主节点和从节点之间的实时数据复制提供了额外的数据保护，并能自动或一键式进行故障切换和故障恢复，为医院信息平台安全稳定运行保驾护航。Odin多功能引擎还具有以下优势：Odin引擎从根本上解决了引擎重启慢的问题：有些品牌引擎重启, 有时需要5、6小时, 用户只得手动删日志等信息, 使重启加快，效率低。Odin先检查核心模块, 启动后再做全面检查、恢复，重启动时间从质上缩短。解决了数据库点重新联接时必须手动启动的问题： Odin已经实现全自动重新连接，无需手动干预。解决了数据量大时引发的各种不稳定问题：Odin多功能引擎大量采用新技术，可以轻松应对每日10,000门诊量。系统的容错性：Odin 引擎可以隔离失败的子系统功能， 防止可能导致整个系统崩溃的故障连锁效应的发生。

高并发(水平扩展，垂直扩展) 高并发(水平扩展，垂直扩展)一、什么是高并发高并发（High Concurrency） 是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指， 通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有 响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数 等。响应时间：系统对请求做出响应的时间。 例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。吞吐量：单位时间内处理的请求数量。 QPS：每秒响应请求数。 在互联网领域，这个指标和吞吐量区分的没有这么明显。并发用户数：同时承载正常使用系统功能的用户数量。 例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。二、如何提升系统的并发能力互联网分布式架构设计， 提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。垂直扩展垂直扩展：提升单机处理能力 。垂直扩展的方式又有两种：（1）增强单机硬件性能例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；（2）提升单机架构性能例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足： 单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。水平扩展水平扩展：只要增加服务器数量，就能线性扩充系统性能。 水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践，是本文重点讨论的内容。三、常见的互联网分层架构常见互联网分布式架构 如上，分为：（1）客户端层：典型调用方是浏览器browser或者手机应用APP（2）反向代理层：系统入口，反向代理（3）站点应用层：实现核心应用逻辑，返回html或者json（4）服务层：如果实现了服务化，就有这一层（5）数据-缓存层：缓存加速访问存储（6）数据-数据库层：数据库固化数据存储整个系统各层次的水平扩展，又分别是如何实施的呢？四、分层水平扩展架构实践反向代理层的水平扩展反向代理层的水平扩展，是 通过“DNS轮询”实现的 ：dns-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问dns-server，会轮询返回这些ip。当nginx成为瓶颈的时候，只要增加服务器数量，新增nginx服务的部署，增加一个外网ip，就能扩展反向代理层的性能，做到理论上的无限高并发。站点层的水平扩展站点层的水平扩展，是 通过“nginx”实现的 。通过修改nginx.conf，可以设置多个web后端。当web后端成为瓶颈的时候，只要增加服务器数量，新增web服务的部署，在nginx配置中配置上新的web后端，就能扩展站点层的性能，做到理论上的无限高并发。服务层的水平扩展服务层的水平扩展，是 通过“服务连接池”实现的 。站点层通过RPC-client调用下游的服务层RPC-server时，RPC-client中的连接池会建立与下游服务多个连接，当服务成为瓶颈的时候，只要增加服务器数量，新增服务部署，在RPC-client处建立新的下游服务连接，就能扩展服务层性能，做到理论上的无限高并发。如果需要优雅的进行服务层自动扩容，这里可能需要配置中心里服务自动发现功能的支持。数据层的水平扩展在数据量很大的情况下，数据层（缓存，数据库）涉及数据的水平扩展，将原本存储在一台服务器上的数据（缓存，数据库）水平拆分到不同服务器上去，以达到扩充系统性能的目的。互联网数据层常见的水平拆分方式有这么几种，以数据库为例：按照范围水平拆分每一个数据服务，存储一定范围的数据，上图为例：user0库，存储uid范围1-1kwuser1库，存储uid范围1kw-2kw这个方案的 好处 是：（1）规则简单，service只需判断一下uid范围就能路由到对应的存储服务；（2）数据均衡性较好；（3）比较容易扩展，可以随时加一个uid[2kw,3kw]的数据服务；不足 是：（1）请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大；按照哈希水平拆分每一个数据库，存储某个key值hash后的部分数据，上图为例：user0库，存储偶数uid数据user1库，存储奇数uid数据这个方案的 好处 是：（1）规则简单，service只需对uid进行hash能路由到对应的存储服务；（2）数据均衡性较好；（3）请求均匀性较好；不足 是：（1）不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移；这里需要注意的是，通过水平拆分来扩充系统性能，与主从同步读写分离来扩充数据库性能的方式有本质的不同。通过水平拆分扩展数据库性能：（1）每个服务器上存储的数据量是总量的1/n，所以单机的性能也会有提升；（2）n个服务器上的数据没有交集，那个服务器上数据的并集是数据的全集；（3）数据水平拆分到了n个服务器上，理论上读性能扩充了n倍，写性能也扩充了n倍（其实远不止n倍，因为单机的数据量变为了原来的1/n）；通过主从同步读写分离扩展数据库性能：（1）每个服务器上存储的数据量是和总量相同；（2）n个服务器上的数据都一样，都是全集；（3）理论上读性能扩充了n倍，写仍然是单点，写性能不变；缓存层的水平拆分和数据库层的水平拆分类似，也是以范围拆分和哈希拆分的方式居多，就不再展开。五、总结高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。 提高系统并发能力的方式，方法论上主要有 两种：垂直扩展（Scale Up）与水平扩展（Scale Out） 。前者 垂直扩展可以通过提升单机硬件性能 ，或者提升单机架构性能，来提高并发性，但 单机性能总是有极限的 ，互联网分布式架构设计 高并发终极解决方 案还是后者： 水平扩展 。互联网分层架构中，各层次水平扩展的实践又有所不同：（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；（2）站点层可以通过nginx来进行水平扩展；（3）服务层可以通过服务连接池来进行水平扩展；（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限。

程序世界里的不信任原则 程序世界里的不信任原则导语人与人之间最重要的是信任，但 程序的世界里，可能信任越少越好；我越发觉得越是高性能高可用的系统里，不信任原则会体现得更加淋漓尽致 。 为了少走弯路，写下这篇文章留给自己参考，其中一些是自己踩过的一些坑；一些是接手他人系统时触过的雷；还有一些是从别人分享的经验学习得来；能力有限，先记下自己的一些体会，错误的地方再慢慢改正。一、编程的世界里十面埋伏编程，是一件容易的事，也是一件不容易的事。说它容易，是因为掌握一些基本的数据类型和条件语句，就可以实现复杂的逻辑；说它不容易，是因为高性能高可用的代码，需要了解的知识有很多很多； 编程的世界，也跟扫雷游戏的世界一样，充满雷区，十面埋伏，一不小心，随时都可能踩雷，随时都可能Game Over。 而玩过扫雷的人都知道，避免踩雷的最好方法，就是提前识别雷区并做标记(设防)避免踩踏。鉴于此， 编程的世界里，从输入到输出同样需要处处设防，步步为营。1、对输入的不信任（1）对空指针的检查不只是输入，只有是使用到指针的地方，都应该先判断指针是否为NULL，而内存释放后，应当将指针设置为NULL。【真实案例】：注册系统某段逻辑，正常使用情况下，都有对指针做检查，在某个错误分支，打印日志时，没检查就使用了该字符串；结果可正常运行，但当访问某个依赖模块超时走到改分支，触发bug，导致 coredump 。（2）对数据长度的检查使用字符串或某段buf，特别是memcpy/strcpy时，需要尽量对数据长度做下检查和截断。【真实案例】：接手oauth系统后运行数月表现良好，突然有一天，发生了coredump，经查，是某个业务不按规定请求包中填写了超长长度，导致memcpy时发生段错误，根本原因，还是没有做好长度检查。（3）对数据内容的检查某些场景下，没有对数据内容做检查就直接使用，可能导致意想不到的结果。【案例】： sql注入和xss攻击都是利用了服务端没有对数据内容做检查的漏洞。2、对输出（变更）的不信任变更的影响一般体现在输出，有时候输出的结果并不能简单的判断是否正常，如输出是加密信息，或者输出的内容过于复杂。所以，对于每次变更（1）修改代码时，采用不信任编码，正确的不一定是“对”的，再小的修改也应确认其对后续逻辑的影响，有些修正可能改变原来错误时的输出，而输出的改变，就会影响到依赖该改变字段的业务。（2）发布前，应该对涉及到的场景进行测试和验证，测试可以有效的发现潜在的问题，这是众所周知的。（3）发布过程，应该采用灰度发布策略，因为测试并非总是能发现问题，灰度发布，可以减少事故影响的范围。常见灰度发布的策略有机器灰度、IP灰度、用户灰度、按比例灰度等，各有优缺点，需要根据具体场景选择，甚至可以同时采用多种的组合。（4）发布后，全面监控是有效发现问题的一种方法。因为测试环境和正式环境可能存在不一致的地方，也可能测试不够完整，导致上线后有问题，所以需采取措施补救A：如使用Monitor监控请求量、成功量、失败量、关键节点等B：使用DLP告警监控成功率C：发布完，在正式环境测试一遍【案例】oauth系统某次修改后编译时，发现有个修改不相关的局部变量未初始化的告警，出于习惯对变量进行了初始化（初始化值和编译器默认赋值不一样），而包头某个字段采用了该未初始化的变量，但在测试用例中未能体现，监控也没细化到每个字段的值，导致测试正常，监控正常；但前端业务齐齐互动使用了该包头字段，导致发布后影响该业务。二、服务程序的世界里防不胜防一般的系统，都会有 上下游 的存在，正如下图所示而上下游的整个链路中，每个点都是不能保证绝对可靠的，任何一个点都可能随时发生故障，让你措手不及。因此， 不能信任整个链路中的任何一个点，需进行设防。1、对服务本身的不信任主要措施如下：（1）服务监控前面所述的请求量、成功量、失败量、关键节点、成功率的监控，都是对服务环节的单点监控。在此基础上，可以加上自动化测试，自动化测试可以模拟应用场景，实现对于流程的监控。（2）进程秒起人可能在程序世界里是不可靠的因素（大牛除外），前面的措施，多是依赖人来保证的；所以，coredump还是有可能发生的，这时，进程秒起的实现，就可以有效减少coredump的影响，继续对外提供服务。2、对依赖系统的不信任可采用柔性可用策略，对于根据模块的不可或缺性，区分关键路径和非关键路径，并采取不同的策略（1）对于非关键路径，采用柔性放过策略当访问非关键路径超时时，简单的可采取有限制（一定数量、一定比重）的重试，结果超时则跳过该逻辑，进行下一步；复杂一点的统计一下超时的比例，当比例过高时，则跳过该逻辑，进行下一步（2）对于关键路径，提供弱化服务的柔性策略关键路径是不可或缺的服务，不能跳过；某些场景，可以根据目的，在关键路径严重不可用时，提供弱化版的服务。举例如派票系统访问票据存储信息严重不可用时，可提供不依赖于存储的纯算法票据，为弥补安全性的确实，可采取缩短票据有效期等措施。3、对请求的不信任（1）对请求来源的不信任有利可图的地方，就会有黑产时刻盯着，伪造各种请求，对此，可采取如下措施A：权限控制如 ip鉴权、模块鉴权、白名单、用户登录态校验 等B：安全审计权限控制仅能打击一下非正常流程的请求，但坏人经常能够成功模拟用户正常使用的场景；所以，对于一些重要场景，需要加入安全策略，打击如IP、号码等信息聚集，频率过快等机器行为，请求重放、劫持等请求）（2）对请求量的不信任前端的请求，不总是平稳的；有活动时，会暴涨；前端业务故障恢复后，也可能暴涨；前端遭到恶意攻击时，也可能暴涨； 一旦请求量超过系统负载，将会发生雪崩，最终导致整个服务不可用，对此种种突发情况，后端服务需要有应对措施A：频率限制，控制各个业务的最大请求量（业务根据正常请求峰值的2-3倍申请，该值可修改），避免因一个业务暴涨影响所有业务的情况发生。B：过载保护，虽然有频率限制，但业务过多时，依然有可能某个时间点，所有的请求超过了系统负载，或者到某个IDC，某台机器的请求超过负载，为避免这种情况下发生雪崩，将超过一定时间的请求丢弃，仅处理部分有效的请求，使得系统对外表现为部分可用，而非完全不可用。三、运营的世界里不可预测1、对机器的不信任机器故障时有发生，如果服务存在单点问题，故障时，则服务将完全不可用，而依赖人工的恢复是不可预期的，对此，可通过以下措施解决（1）容灾部署即至少有两台以上的机器可以随时对外提供服务。（2）心跳探测用于监控机器是否可用，当机器不可用时，若涉及到主备机器的，应做好主备机器的自动切换；若不涉及到主备的，禁用故障机器对外提供服务即可。2、对机房的不信任现实生活中，整个机房不可用也是有发生过的，如2015年的天津滨海新区爆炸事故，导致腾讯在天津的多个机房不能对外提供正常服务，对此采取的措施有：（1）异地部署不同IDC、不同城市、不同国家等部署，可用避免整个机房不可用时，有其他机房的机器可以对外提供服务（2）容量冗余对于类似QQ登陆这种入口型的系统，必须保持两倍以上的冗余；如此，可以保证当有一个机房故障时，所有请求迁移到其他机房不会引发系统过载。3、对电力的不信任虽然我们越来越离不开电力，但电力却不能保证一直在为我们提供服务。断电时，其影响和机器故障、机房故障类似，机器会关机，数据会丢失，所以，需要对数据进行备份。（1）磁盘备份来电后，机器重启，可以从磁盘中恢复数据，但可能会有部分数据丢失。（2）远程备份机器磁盘坏了，磁盘的数据会丢失，使用对于重要系统，相关数据应当考虑采用远程备份。4、对网络的不信任（1）不同地方，网络时延不一样一般来说，本地就近的机器，时延要好于异地的机器, 所以，比较简单的做法就是近寻址，如CMLB。也有部分情况，是异地服务的时延要好于本地服务的时延，所以，如果要做到较好的最优路径寻址，就需要先做网络探测，如Q调（2）常有网络有波动或不可用情况和机器故障一样处理，应当做到自动禁用；但网络故障和机器故障又不一样，经常存在某台机器不可用，但别的机器可以访问的情况，这时就不能在服务端禁用机器了，而应当采用本地回包统计策略，自动禁用服务差机器；同时需配合定时探测禁用机器策略，自动恢复可正常提供服务机器。5、对人的不信任人的因素在运营的世界里其实是不稳定的因素（大牛除外），所以，不能对人的操作有过多的信任。（1）操作备份每一步操作都有记录，便于发生问题时的回溯,重要的操作需要 review ，避免个人考虑不周导致事故。（2）效果确认实际环境往往和测试环境是存在一些差异，所有在正式环境做变更后，应通过视图review和验证来确认是否符合预期。（3）变更可回滚操作前需对旧程序、旧配置等做好备份，以便发生故障时，及时恢复服务。（4）自动化部署机器的部署，可能有一堆复杂的流程，如各种权限申请，各种客户端安装等，仅靠文档流程操作加上测试验证时不够的，可能某次部署漏了某个步骤而测试又没测到，上线后就可能发生事故若能所有流程实现自动化，则可有效避免这类问题。（5）一致性检查现网的发布可能因某个节点没同步导致漏发，也就是不同的机器服务不一样；对此，有版本号的，可通过版本号监控发现；没版本号的，则需借助进程、配置等的一致性检查来发现问题。四、小结备注：以上提到的不信任策略，有的不能简单的单条使用，需要结合其他的措施一起使用的。好了，先写这么多。最重要的还是那句话，程序的世界里，应该坚持不信任原则，处处设防。

并发和并行的区别 并发和并行的区别区别并发（concurrency）和并行（parallellism）是：解释一：并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔发生。解释二：并行是在不同实体上的多个事件，并发是在同一实体上的多个事件。解释三：并行是在多台处理器上同时处理多个任务。如 hadoop 分布式集群，并发是在一台处理器上“同时”处理多个任务。所以 并发编程的目标是充分的利用处理器的每一个核，以达到最高的处理性能。并行(parallel)并行(parallel)：指在同一时刻，有多条指令在多个处理器上同时执行。所以无论从微观还是从宏观来看，二者都是一起执行的。并发(concurrency)并发(concurrency)：指在同一时刻只能有一条指令执行，但多个进程指令被快速的轮换执行，使得在宏观上具有多个进程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个进程快速交替的执行。并行在多处理器系统中存在，而并发可以在单处理器和多处理器系统中都存在，并发能够在单处理器系统中存在是因为并发是并行的假象，并行要求程序能够同时执行多个操作，而并发只是要求程序假装同时执行多个操作（每个小时间片执行一个操作，多个操作快速切换执行）。当有多个线程在操作时，如果系统只有一个 CPU，则它根本不可能真正同时进行一个以上的线程，它只能把 CPU 运行时间划分成若干个时间段，再将时间段分配给各个线程执行，在一个时间段的线程代码运行时,其它线程处于挂起状态.这种方式我们称之为并发（Concurrent）。当系统有一个以上 CPU 时，则线程的操作有可能非并发。当一个 CPU 执行一个线程时，另一个 CPU 可以执行另一个线程，两个线程互不抢占 CPU 资源，可以同时进行，这种方式我们称之为并行（Parallel）。