可用性

一、什么是OCTO 定义： OCTO是美团的分布式服务通信框架及服务治理系统，属于公司级基础设施(octo已经开源，https://github.com/Meituan-Dianping。 octo-rpc, octo-portal，octo-ns 都是octo的一部分)。 目标： 为公司所有业务提供统一的服务通信框架，使业务具备良好的服务运营能力，轻松实现服务注册、服务自动发现、负载均衡、容错、灰度发布、调用数据可视化等，持续提升服务高可用性、服务运维效率。 类比： 美团点评内部类似的框架还有pigeon（已开源，https://github.com/dianping/pigeon）。OCTO是octopus（章鱼）的缩写，pigeon是鸽子的意思，一个水里游，一个天上飞，目标大体一致。 业界同类产品有Dubbo。OCTO的功能因为主要内部用，功能要丰富的多。 规模： 千亿级别 静儿的老领导17年时做过一个QCon分享，叫《OCTO：千亿规模下的服务治理挑战与实践》。里面提到了16年OCTO日调用量已经超过千亿，目前这个数字还在高速增长。 二、产生背景 阶段1 - 垂直应用阶段 这个阶段大体相当于目前运用最广泛的「分层架构」。把业务按照领域划分（垂直拆分），将一个大应用分成几个互不相干的小应用。 阶段2 - 早期分布式阶段 随着规模的扩大，系统之间需要进一步拆分

很多学员都在反馈，说zk很难学，学的不是很明白，在这里，我继续带着大家详解一遍Zookeeper 首先zk是什么呢首先肯定是一个个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用 中经常遇到的一些数据管理问题，如：统一命名服务、集群管理、分布式应用配置项的管理 等。 第二：Zookeeper是一个数据库 第三：Zookeeper是一个拥有一件系统特点的数据库 第四：Zookeeper是一个解决了数据一致性问题的分布式数据库 第五：Zookeeper是一个具有发布和订阅功能的分布式数据库 (watch) 这样说同学们应该都是认同的吧，没有异议的吧 那么这个一致性又是什么呢 一致性分为强一致性，弱一致性， 最终一致性 有些同学不是很懂哈，那就接着看下面的内容 强制要求步骤2读取的时候，一定要读取的是2，不能读取到的是1，那么要求数据库之间同步异常迅速或者在步骤2上加锁以等待数据同步完成，那么这种叫强一致性； 允许步骤2读取的时候，可以读取的是1，那么这种叫弱一致性，其实就是不需要要一致； 允许步骤2读取的时候，可以先读到 1，过一段时间再读到2，那么这种叫最终一致性，就是可以等待一段时间才一致； 一个集群需要对外部提供强一致性，所以只要集群内部某一台服务器的数据发生了改变，那么就需要等待集群内其他服务器的数据同步完成后才能正常的对外提供服务。

目录 引言 HDFS 数据块的设计 数据块应该设置成多大？ 抽象成数据块有哪些好处？ 操作块信息的命令 HDFS 中节点的设计 有几种节点类型？ 用户如何访问 HDFS？ 如何对 namenode 容错？ 如何更快的访问 datanode 中访问频繁的块？ 如何扩展 namenode 以存储更多的文件？ HDFS 中的高可用性设计 如何处理 namenode 单点失效问题？ namenode 间如何共享编辑日志？ namenode 如何能快速故障切换？ 如何规避非平稳故障转移？ 小结 参考文档 珍惜时间，时间要花在做有用的事情上，力戒无意义的举动 ——富兰克林 引言 当数据的大小大于一台独立的电脑的存储能力时，就有必要对它进行分区并且存储在多台单独的电脑上。要将非常大的数据集合存储在多台电脑上，就会涉及到多台电脑共享的文件系统，也就是分布式文件系统。 分布式文件系统(distributed file system) 是指管理网络中跨多台计算机存储的文件系统。 分布式文件系统既然跨多台电脑，通过网络将它们互联起来，就可能会出现其中的一个电脑节点连接中断或者宕机的情况，也就是节点故障。在这种情况下也不能出现丢失整个文件系统任何数据的情况，怎么来做到呢？先让我们用发散思维的方式来思考一下。 将文件系统的每份数据备份，并且备份不能在同一台物理计算器上，这样能保证即使其中一台计算机宕机

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 分区容忍性是我们必须需要实现的。 所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 ======================================================================================================================= C:强一致性 A：高可用性 P：分布式容忍性 CA 传统Oracle数据库 AP 大多数网站架构的选择 CP Redis、Mongodb 注意：分布式架构的时候必须做出取舍。 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。 因此牺牲C换取P，这是目前分布式数据库产品的方向 ======================================================================================================================= 一致性与可用性的决择 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地 数据库事务一致性需求 　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，

　　 NoSql数据模型简介 　　聚合模型：KV键值，BSON 　　列族： 　　图形，这里的图形不是指真正的图形，而是关系图 　　 NoSql数据库的四大分类 　　KV键值：BerkeleyDB,Redis,tair,memcache 　　文档型数据库：couchDB,mongoDB 　　列存储数据库：Cassandra,HBase,分布式文件系统 　　图关系数据库：Neo4J,InfoGrid 　　对比： 　　 分布式数据库的CAP+BASE 　　传统的ACID：A(atom icity):原子性 C(Consistency):一致性 I(Isolation):独立性 D(Durability):持久性 　　CAP：C(Consistency)：强一致性；A(Availability)：可用性；P(Patition Tolerance)：分区容错性 　　 CAP3进2： 　　CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 　　而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 　　分区容忍性是我们必须需要实现的。 　　所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 ======================================================================================

入门概述： 1.为什么要用到NoSQL 　　a) 单机MySQL的美好年代，在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。 　　上述架构下，我们来看看数据存储的瓶颈是什么？ 　　1.数据量的总大小 一个机器放不下时 　　2.数据的索引（B+ Tree）一个机器的内存放不下时 　　3.访问量(读写混合)一个实例不能承受 　　 如果满足了上述1 or 3个，进化...... 　　b) Memcached(缓存)+MySQL+垂直拆分，后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技术产品。 　　 Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展

原文网址：http://geek.csdn.net/news/detail/97879 【 摘要 】本文谈及一些分布式系统的理论和思想，包括 CAP、BASE、NWR 等。并简单分析一些主流数据库分布式方案的利弊，以便我们在开发时更深入全面地进行思考、选择和设计。以下为正文： 在讨论常见架构前，先简单了解下 CAP 理论： CAP是Consistency、Availablity和Partition-tolerance的缩写。分别指： 一致性（Consistency）：每次读操作都能保证返回的是最新数据； 可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果； 分区容忍性（Partition-tolerance）：当节点间出现网络分区，照样可以提供服务。 CAP理论指出：CAP三者只能取其二，不可兼得。其实这一点很好理解： 首先，单机系统都只能保证CP； 有两个或以上节点时，当网络分区发生时，集群中两个节点不能互相通信。此时如果保证数据的一致性C，那么必然会有一个节点被标记为不可用的状态，违反了可用性A的要求，只能保证CP； 反之，如果保证可用性A，即两个节点可以继续各自处理请求，那么由于网络不通不能同步数据，必然又会导致数据的不一致，只能保证AP。 一、单实例 单机系统很显然，只能保证CP，牺牲了可用性A。单机版的MySQL、Redis

1. VSTS的失效类型 (1) TFS数据库内容失效:数据被错误删除 (2) TFS数据库服务失效:数据服务不能启用 (3) TFS应用层服务失效:应用层服务不能启用 (4) TFS客户端失效（本文不考虑） (5) 网络失效（本文不考虑） 2. VSTS高可用性方案 (1)无备机的备份方案 (2) 有备机的备份方案 (3) 热待机系统 (4) 热待机系统+数据库群集 3. 无备机的备份方案 基于数据库的备份与恢复技术。 如果数据损坏，通过恢复到上一次备份点上，保证VSTS的可用性。恢复时间： 30分钟。 如果数据库服务或应用层服务失效，则重装TFS，并恢复数据库。恢复时间：一天。 成本：一台TFS服务器，一台可共享文件的服务器。 4. 有备机的备份方案 基于数据库的备份与恢复技术。 如果数据损坏，通过恢复到上一次备份点上，保证VSTS的可用性。恢复时间： 30分钟。 如果数据库服务或应用层服务失效，将数据库恢复同名的备机上。恢复时间：2小时。 成本：两台TFS服务器，一台可共享文件的服务器。 5. 热待机系统 两台在线的TFS应用服务器，一台主服务器，一台备用服务器，此方案能保证应用层的主可用性。 如果数据损坏，通过恢复到上一次备份点上，保证VSTS的可用性。恢复时间：30分钟。 如果应用层服务失效，启用另一台备用的应用服务器。恢复时间：10分钟。 如果数据库服务失效

什么场景下会产生分布式事务？ 在支付异步回调的情况下，支付宝发送http请求给第三方平台，第三方平台需要更改支付状态以及订单状态，在此场景下，第三方平台更改本地支付数据库的支付状态后，通知订单服务更改订单的状态，在此程序后，如果代码出现异常，由于有声明式事务的存在，本地支付服务的数据库会进行回滚，变成未支付状态，但是订单服务的状态却无法回滚，订单服务的订单的状态变成已支付状态，这就出现了订单数据库和支付数据库数据不一致的情况，这便是分布式事务产生的场景之一。 什么是分布式事务？ 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。以上是百度百科的解释，简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 分布式事务的理论 1、cap理论 1）数据一致性（consistency） 如果系统对一个写操作返回成功，那么之后的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据，对调用者而言数据具有强一致性(strong consistency) (又叫原子性 atomic、线性一致性 linearizable consistency) 一致性指

Kafka ISR kafka replica Data Replication如何Propagate(扩散出去)消息？ Data Replication何时Commit？ Data Replication如何处理Replica恢复 Data Replication如何处理Replica全部宕机 kafka replica 当某个topic的replication-factor为N且N大于1时，每个Partition都会有N个副本(Replica)。kafka的replica包含leader与follower。 Replica的个数小于等于Broker的个数，也就是说，对于每个Partition而言，每个Broker上最多只会有一个Replica，因此可以使用Broker id 指定Partition的Replica。 所有Partition的Replica默认情况会均匀分布到所有Broker上。 Data Replication如何Propagate(扩散出去)消息？ 每个Partition有一个leader与多个follower，producer往某个Partition中写入数据时，只会往leader中写入数据，然后数据才会被复制进其他的Replica中。 数据是由leader push过去还是有flower pull过来？