可用性

分布式架构设计 1.分布式架构的基本理论 2.SOA架构和微服务架构 3.领域驱动设计及业务驱动划分 ==================================== 一. 分布式架构的基本理论 1.CAP理论 一个经典的分布式系统理论。CAP 理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。 一致性（Consistency） 所有节点上的数据必须时刻保持一致 可用性（Availability） 可用性是指服务一直可用，而且是正常的响应时间 分区容错性（Partition tolerance） 系统应该持续提供服务，即时系统内部（某个节点分区）有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂；服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系 总结： CAP 并不是一个普适性原理和指导思想，它仅适用于原子读写的 NoSql 场景中，并不适用于数据库系统。 2.BASE理论 从前面的分析中知道：在分布式（数据库分片或分库存在的多个实例上）系统下，CAP 理论并不适合数据库事务（因为更新一些错误的数据而导致的失败，无论使用什么样的高可用方案都是徒劳

一、zookeeper宕机 　　zookeeper注册中心宕机，还可以消费dubbo暴露的服务 　　健壮性： 监控中心宕掉不影响使用，只是丢失部分采样数据 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务 注册中心对等集群，任意一台宕掉后，将自动切换到另一台 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯 服务提供者无状态，任意一台宕掉后，不影响使用 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复 二、dubbo直连 　　 在开发和测试环境中，通常需要绕过注册中心，只测试指定的服务提供者。在这种情况下，可能需要点对点直接连接，而服务提供者将忽略提供商注册提供程序的列表。接口A配置点对点，不影响B接口从注册表获取列表. 　　 　　 2.1 用xml配置 <dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" /> 　　2.2 配置 -d 　　将-D参数映射服务地址添加到JVM启动参数： java -Dcom.alibaba.xxx.XxxService=dubbo://localhost:20890 　 　2.3 配置.properties档案 （详情请参考官网） 　 三

　本文只是一个概念，具体配置太多，这里不做细节描述。 　　1、分布式应用的概念和优势 　　分布式数据库是指利用高速网络将物理上分散的多个数据 存储 单元连接起来组成一个逻辑上统一的数据库。分布式数据库的基本思想是将原来集中式数据库中的数据分散存储到多个通过网络连接的数据存储节点上，以获得更大的存储容量和更高的并发访问量。近年来，随着数据量的增长，分布式数据库技术也得到了快速的发展，传统的关系型数据库开始从集中式模型向分布式存储，从集中式计算走向分布式计算。 　　分布式数据库系统的主要目的是容灾、异地数据备份，并且通过就近访问原则，用户可以就近访问数据库节点，这样就实现了异地的负载均衡。同时，通过数据库之间的数据传输同步，可以分布式保持数据的一致性，这个过程完成了数据备份，异地存储数据在单点故障的时候不影响服务的访问，只需要将访问流量切换异地镜像就行。 　　分布式数据库应用的优势如下： 　　(1)适合分布式数据管理，能够有效提高系统性能。 　　(2)系统经济性和灵活性好。 　　(3)系统的可靠性和可用性强。 　　2、mysql分布式应用的主要技术 　　(1)mysql数据切割 　　数据切割(sharding)是指通过某种特定的条件，将存放在同一数据库中的数据分散存放到多个数据库(主机)上面，以达到分散单台设备负载的效果。数据切分还可以提高系统的总体可用性，因为单台crash之后

Redis 的几种常见使用方式包括： 单机模式 主从模式 哨兵模式(sentinel) 集群模式(cluster) 第三方模式 单机模式 Redis 单副本，采用单个 Redis 节点部署架构，没有备用节点实时同步数据，不提供数据持久化和备份策略，适用于数据可靠性要求不高的纯缓存业务场景。 优点： 架构简单，部署方便。 高性价比：缓存使用时无需备用节点(单实例可用性可以用 supervisor 或 crontab 保证)，当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务。 高性能。 缺点： 不保证数据的可靠性。 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务。 高性能受限于单核 CPU 的处理能力(Redis 是单线程机制)，CPU 为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用 Memcached 替代。 主从模式 Redis 采用主从(可以多从)部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。 优点： 高可靠性：一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服务

网站的页面能完整呈现在最终用户面前，需要经过很多环节，任何一个环节出了问题，都可能导致网站页面不可访问。 DNS会被劫持、CDN服务器可能会挂掉、网站服务器可能会宕机、网络交换机可能会失效.......都可能会导致网站不可用。 网站不可用也被称作网站故障，业界通常用多少个9来衡量网站的可用性， 如QQ的可用性是4个9，即QQ服务99.99%可用，这意味着QQ服务器在其所有运行时间中， 只有0.01%的时间不可用，也就是一年之中大约最多53分钟不可用。 　　网站不可用时间（故障时间）= 故障修复时间点 - 故障发现（报告）时间点 　　网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）X 100% 对于大多是网站而言： 2个9是基本可用，网站年度不可用时间小于88小时； 3个9是较高可用，网站年度不可用时间小于9小时； 4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟； 5个9是极高可用性，网站年度不可用时间小于5分钟。 由于可用性影响因素很多，对于网站整体而言，达到4个9，乃至5个9的可用性， 除了过硬的技术、大量设备资金的投入和工程师的责任心，还要有个好运气。 常使用Twitter的用户或多或少遇到过那个著名的服务不可用的鲸鱼页面，事实上Twitter网站的可用性不足2个9。 来源： https://www.cnblogs.com/JavaHxm/p

一般来说，构建分布式系统的目的一是增加系统容量，二是提高系统的可用性。转换成技术方面，也就是宛成以下两件事。 大流量处理。通过集群技术把大规模并发请求的负载分散到不同的机器上 关键业务保护。提高后台服务的可用性，把故障隔离起来阻止多米诺骨牌效应（雪崩效应）。如果流量过大，需要到业务降级。 说白了就是干两件事，一是提高整体架构的吞吐量，服务更多的并发和流量，二是提高系统的稳定性，让系统的可用性更高。 提高架构的性能 提高架构的稳定性 分布式系统的关键技术 引入分布式系统，会引入一堆技术问题，需要从以下几个方面解决 服务治理。服务拆分、服务调用、服务发现，服务依赖，服务的关键度定义……服务治理的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。 架构软件管理。服务之间有依赖，而且有兼容性问题，所以，整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理，以及对服务的编排、聚合、事务处理等服务调度功能。 DevOps。分布式系统可以更为快速地更新服务，但是对于服务的测试和部署都会是挑战。所以，还需要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署等。 自动化运维。有了 DevOps 后，我们就可以对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术了。 资源调度管理

官网提供： 禁用高可用性 转到HDFS服务。 选择操作>禁用高可用性。 选择NameNode和SecondaryNameNode的主机，然后单击Continue。 选择HDFS检查点目录并单击继续。 确认您要采取此操作。 更新Hive Metastore NameNode。 Cloudera Manager确保一个NameNode处于活动状态，并保存命名空间。 然后停止备用NameNode，创建SecondaryNameNode，删除备用NameNode角色，并重新启动所有HDFS服务。 来源： oschina 链接： https://my.oschina.net/u/3197158/blog/1625325

浅谈分布式一致性与CAP/BASE/ACID理论 https://www.cnblogs.com/zhang-qc/p/6783657.html 　　 ##转载请注明 　　CAP理论（98年秋提出，99年正式发表）： C（ Consistency）一致性： 在分布式系统中，数据一致更新，所有数据变动都是同步的； A（ Availability）可用性： 分布式系统中，部分节点故障，系统是否依然可响应客户端请求（对数据更新具备高可用性）； P（ Partition tolerance）分区容错性： 分区是相对于通信的时延要求来讲，指在时延要求内部分节点与其它节点联系不可达，在该情况下系统是否依然可用（可靠性）。该场景下不同于节点宕机情况，可能由于网络交换器故障，使形成不同分区，分区不可达，或者是当前延迟过大，超过了设定的值。 点对点的网络上，复杂的拓扑结构和独立的路由选择可能使连接具有非对称（asymmetric）、非传递的特性，使进程间不可以通信。 由于网络存在延迟和丢包等问题，P性质相对必须满足，所以常在C和A之间进行权衡。CAP理论说明系统的架构只能满足三点中的二点，无法设计出满足三点的完美的系统。可理解为：网络环境是不可靠的，因此会存在分区的发生，如果数据仅单点存储，那么其余分区的节点无法访问，因此分区无法容错。可以增加该数据项的备份，这样发生分区后各分区仍有该数据

High Availability 高可用性 Verticles can be deployed with High Availability (HA) enabled. In that context, when a verticle is verticle可以发布为“高可用性”的，这样的话当一个verticle被发布到一个实例上突然死掉了， deployed on a vert.x instance that dies abruptly, the verticle is redeployed on another vert.x instance from the cluster. 这个verticle会被重新发布到集群的另外一个vert.x的实例上。 To run an verticle with the high availability enabled, just append the -ha switch: 运行verticle为高可用性，只要追加参数-ha。 vertx run my-verticle.js -ha When enabling high availability, no need to add -cluster . 在启用高可用性时，不用追加-cluster参数。 More details about the high availability

场景一： 某智能家居厂家，用户喊出“小X同学，帮我扫地”后，服务器宕机了，扫地机器人不能立即启动，于是，用户可能再连续喊几次后，无奈又习惯的按下了扫地机器人的启动按钮。 场景二： 某高层建筑有2000个房间，10个房间烟感连续发出报警，理论上出现了火灾并在逐步扩散，恰巧，服务器又宕机了，然后... 两个场景都是服务器宕机，但后果却不同，根据业务实际情况，我们必须考虑软件架构的高可用性。 有人会说，上云吧，上云比自己搭建服务器稳定多了。通常情况下是这样的，但是，不要忽略SLA这个重要的概念，云产品都是有SLA的，SLA是什么呢？SLA全称是ServiceLevel Agreement，翻译为服务水平协议，他表明了公有云提供服务的等级以及质量。比如我们说月度99.95%的SLA，意味着每个月服务出现故障的时间只能占总时间的0.05%,如果这个月是30天，那么约等于21.6分钟。 对于场景一，或许21.6分钟是可容忍的，但对于场景二，绝对是不允许的。 针对各种高可用方案，通常会提到下面这些概念（不是针对Azure的概念）： 同城 容灾 同城 容灾 是在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同城灾难备份的数据中心与灾难备份中心的距离比较近，通信线路质量较好