高可用

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。 所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务 一、业务场景介绍 咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。 那对一个订单支付之后，我们需要做下面的步骤： 更改订单的状态为“已支付” 扣减商品库存 给会员增加积分 创建销售出库单通知仓库发货 这是一系列比较真实的步骤，无论大家有没有做过电商系统，应该都能理解。 二、进一步思考 好，业务场景有了，现在我们要更进一步，实现一个 TCC 分布式事务的效果。 什么意思呢？也就是说，[1] 订单服务-修改订单状态，[2] 库存服务-扣减库存，[3] 积分服务-增加积分，[4] 仓储服务-创建销售出库单。 上述这几个步骤，要么一起成功，要么一起失败，必须是一个整体性的事务。 举个例子，现在订单的状态都修改为“已支付”了，结果库存服务扣减库存失败。那个商品的库存原来是 100 件，现在卖掉了 2 件，本来应该是 98 件了。 结果呢？由于库存服务操作数据库异常，导致库存数量还是 100。这不是在坑人么，当然不能允许这种情况发生了！ 但是如果你不用 TCC 分布式事务方案的话，就用个 Spring

阿里P8架构师谈：如何设计淘宝亿级系统架构！ 优知学院 2018-09-20 18:31:30 类似淘宝这样的大型网站，需要涉及到如下架构设计技术 1.业务拆分 应用程序拆分，拆分后如何通讯、拆分步骤、拆分的原则等。 比如我以淘宝为例：根据业务属性进行垂直切分，划分为商品，订单系统、用户系统、购物车系统，支付系统，评论系统，客服系统等，系统拆分后会涉及到消息通讯机制，以及以下的集群部署。 2.应用集群部署（分布式部署，集群部署和负载均衡） 分布式部署：将业务拆分后的应用单独部署，应用直接通过类似Dubbo远程通信； 集群部署：电商网站的高可用要求，每个应用至少部署N台服务器进行集群部署； 负载均衡：是高可用系统必须的，一般应用通过负载均衡实现高可用，分布式服务通过内置的负载均衡实现高可用，关系型数据库通过主备方式实现高可用。 3.分布式中间件技术 分布式缓存：Redis为代表的，以及TFS、GFS、HDFS为代表的分布式文件存储等。 4.单点登录（分布式Session） 系统分割为多个子系统，独立部署后，不可避免的会遇到会话管理的问题。一般可采用Session同步，Cookies，分布式Session方式，大型网站一般采用分布式Session实现。 5.数据库集群（垂直拆分、读写分离，分库分表） 数据库的数据量过大之后，需要按照业务为单位进行数据库垂直拆分。淘宝为例，拆分为商品库

运维之道 | Redis 哨兵（Sentinel）深入剖析 及 Sentinel 搭建部署（高可用） 前言 Redis高可用概述 在 Web 服务器中，高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服（99.9%、99.99%、99.999% 等等）。在 Redis 层面，高可用的含义要宽泛一些，除了保证提供正常服务（如主从分离、快速容灾技术 等），还需要考虑数据容量扩展、数据安全 等等。 在 Redis 中，实现 高可用的技术 主要包括 持久化 、 复制 、 哨兵 和 集群 ，下面简单说明它们的作用，以及解决了什么样的问题： 持久化 ：持久化是最简单的高可用方法。它的主要作用是 数据备份 ，即将数据存储在 硬盘，保证数据不会因进程退出而丢失。 主从复制 ：复制是高可用 Redis 的基础，哨兵和集群都是在复制基础上实现高可用的。 复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复 。缺陷是故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。 哨兵 ：在复制的基础上， 哨兵实现了自动化的故障恢复 。缺陷是写操作无法负载均衡，存储能力受到单机的限制。 集群 ：通过集群，Redis 解决了写操作无法负载均衡以及存储能力受到单机限制的问题， 实现了较为完善的高可用 方案。 主从切换技术的方法是 ：当主服务器宕机后

文章目录 五大核心组成 协议 AMQP MQTT OpenMessage协议 Kafka协议 持久化 消息分发 高可用 主从共享 主从同步 多主集群同步部署 多主集群转发部署模式 Master-Slave 和 Broker-Cluster 的组合 高可靠 五大核心组成 协议 持久化机制 消息分发机制 高可用设计 高可靠设计 协议 三要素 语法 语义 时序（同步） 消息中间件常见协议：OpenWire、AMQP、MQTT、Kafka、OpenMessage 为什么消息中间件不用 HTTP 协议 —— HTTP 太大，并且是短连接 AMQP 高级消息队列协议即 Advanced Message Queuing Protocol（AMQP) 特性： 支持事务、持久化，可靠性好 MQTT MQTT (Message Queuing Telemetry Transport) 消息队列遥测传输是 IBM 开发的一个即时通讯协议，物联网系统架构中的重要组成部分。 特性： 轻量、结构简单、传输快、没有事务支持、没有持久化相关设计 应用场景： 适用于计算能力有限、低带宽、网络不稳定的场景 OpenMessage协议 OpenMessaging 是近一两年由阿里发起，与雅虎、滴滴出行、StreamIio等公司共同参与创立的分布式消息中间件、流处理领域的应用开发标准。是 国内

点击 下载 文档，查看本文所有相关资料。 https://163.53.94.133/assets/uploads/files/large-scale-cloud-yy.pdf 今天的分享偏技术一些，首先我们来看SDN的本质，然后从Tungsten Fabric（以下简称TF）架构上解析为什么比OVS更好，为什么能支撑更大的场景。 先来看云对网络的要求。首先是租户隔离，IaaS就是多租户，对于地址重用的要求，以VLAN的传统方式也是可以实现的。另外，传统VXLAN的协议或OVS的协议，只提供二层隔离的能力，没有三层隔离的能力，只要你的机器绑到外网IP，或者绑到公共的路由层面上，三层是可以互通的，所以说在租户隔离的层面，也有三层隔离的需求。 其次，云需要网络支持虚拟机跨机柜的迁移。VXLAN的话还要跨数据中心大二层，不是说不可以实现，但除了网络要求，还有存储的要求，比较难。虚拟机跨机柜的迁移，最难的是什么？传统网络架构，就是接入-汇聚-核心，路由器以下都是二层架构，机器可以在不同机架上迁移，但一个数据中心，云足够大的时候，二层基础网络是支撑不了整个云的，不同机架在不同三层里面，这时虚拟机做迁移就要要求IP地址不能变。 另外，还有网络功能和服务的要求。在云上面都是共享的资源池，如果以负载均衡为例，将一个性能强大的硬件负载均衡虚拟化给多个租户使用

节点主从（镜像全量）+哈希slot（分片） 无主模型 遵循 CAP原则 C一致性 A可用性 P分区容错性，三者不可兼得 数据放在大数据集群中的方式/集群承载数据的方式：分片 镜像全量 镜像全量 优：做数据的高可用（节点不单一），不担心某一个节点故障，数据在其他节点有相同备份 缺：占用内存资源，横向来说，没有对数据的扩展能力（4G–>12G） 分片 优：横向扩展能力强 缺：没有备份 CRUD操作 增加(Create)、读取查询(Retrieve)、更新(Update)和删除(Delete) 主从复制 主可以进行CRUD所有操作 从只能R 主从模型 图上能看得到的信息： 只有1个Master，可以有N个slaver，而且Slaver也可以有自己的Slaver，由于这种主从的关系决定他们是在配置阶段就要指定他们的上下级关系，而不是Zookeeper那种平行关系是自主推优出来的。 读写分离，Master只负责写和同步数据给Slaver，Slaver承担了被读的任务，所以Slaver的扩容只能提高读效率不能提高写效率。 Slaver先将Master那边获取到的信息压入磁盘，再load进内存，client端是从内存中读取信息的，所以Redis是内存数据库。 当一个新的Slaver加入到这个集群时，会主动找Master来拜码头，Master发现新的小弟后将全量数据发送给新的Slaver

什么是LVS负载均衡 ？ 可伸缩网络服务涉及到几种不同的结构，它们都需要一个前端的负载调度器（或者多个进行主从备份）。 先分析实现虚拟网络服务的主要技术，指出 <strong>IP</strong> 负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术中，主要有通过网络地址转换NAT（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，称之为VS/NAT技术（Virtual Server via Network Address Translation）。在分析VS/NAT的缺点和网络服务的非对称性的基础上，提出了通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。VS/NAT、VS/TUN和VS/DR技术是LVS集群中实现的三种IP负载均衡技术。 企业群及应用概述 群集的含义 Cluster，集群、群集 由多台主机构成，但对外只表现为一个整体 在互联网应用中 ，随着站点对硬件性能、响应速度、服务稳定性、数据可靠性等要求越来越高，单台服务器力不从心 解决方法 使用价格昂贵的小型机、大型机

容器技术是和我们的宿主机共享硬件资源及操作系统，可以实现资源的动态分配。容器包含应用和其所有的依赖包，但是与其他容器共享内核。容器在宿主机操作系统中，在用户空间以分离的进程运行。 通过使用容器，我们可以轻松打包应用程序的代码、配置和依赖关系，将其变成容易使用的构建块，从而实现环境一致性、运营效率、开发人员生产力和版本控制等诸多目标。容器可以帮助保证应用程序快速、可靠、一致地部署，其间不受部署环境的影响。容器还赋予我们对资源更多的精细化控制能力，让我们的基础设施效率更高。通过下面这幅图我们可以很直观的反映出这两者的区别所在。 Docker****的优势 Docker****相比于传统虚拟化方式具有更多的优势： · docker 启动快速属于秒级别。虚拟机通常需要几分钟去启动 · docker 需要的资源更少，docker在操作系统级别进行虚拟化， docker 容器和内核交互，几乎没有性能损耗，性能优于通过 Hypervisor 层与内核层的虚拟化 · docker 更轻量， docker 的架构可以共用一个内核与共享应用程序库，所占内存极小。同样的硬件环境， Docker 运行的镜像数远多于虚拟机数量，对系统的利用率非常高 · 与虚拟机相比， docker 隔离性更弱， docker 属于进程之间的隔离，虚拟机可实现系统级别隔离 · 安全性： docker 的安全性也更弱。

1.前言&基本介绍 　　 　　在原始的系统架构中，我们都由程序直接连接DB，随着业务的进一步开展，DB的压力越来越大，为了缓解DB的这一压力，我们引入了缓存，在程序连接DB中加入缓存层， 从而减轻数据库压力，而且缓存一般存在于内存中，相比于存在硬盘中的DB在读取速度上绝对是比DB高几个等级。下面我们来简单聊聊关于缓存几个东西 2.缓存的优缺点 　　　　缓存的优点就是“快”，一个快字基本能概括了。如上文说的加速读写，分流对数据库的压力，归根结底就是对快字的应用及其本身，缺点主要是如下三点： 　　　　　　1.数据不一致性：DB的数据与缓存中的数据不一致 　　　　　　2.开发成本：需要同时处理缓存层跟DB层的逻辑，增加了开发成本 　　　　　　3.维护成本：例如需要对缓存层进行一个监控，增加了运维的成本 3.缓存更新策略 　　　　在上面中我们说到数据不一致性，一般来说缓存也是需要有生命周期的，需要被更新或者删除，这样才能保持缓存的可控性，在缓存更新中有如下三点： 　　　　　　1.LR(F)U/FIFO算法删除：简单来说就是按照队列的形式对不常用的缓存进行删除，链表的形式来实现，具体可点这里 http://blog.csdn.net/maddemon/article/details/6650703 　　　　　　2.超时删除：在设置缓存的时候可以设置过期时间，在时间到期之后自动删除

导读 本文转载自MySQL解决方案工程师 作者：徐铁韬 这篇文章将详细地介绍MySQL的高可用解决方案—— MySQL InnoDB Cluster。 说到高可用性，首先要了解一下什么是高可用性？ 高可用性要求的实际上是对可靠性的要求，从本质上来说，是通过技术和工具来提高可靠性，尽可能长时间保持数据的可用和系统的正常运行时间。实现高可用性的原则为排除单点故障、通过冗余实现快速恢复，并且具有容错机制。 上面一页主要介绍了几个关键词汇，以及相关的定义，这些有助于理解可靠性和高可用性。 MySQL的高可用性解决方案目前大致分为5种，按照高可用的级别（99.9999%为最高级）排序依次为，主从复制、具有自动故障转移功能的主从复制、利用共享存储、OS或虚拟化软件实现主备架构、MySQL Group Replication 群组复制，以及MySQL NDB Cluster。 MySQL Replication：允许数据从一台实例上复制到一台或多台其它的实例上。 MySQL Group Replication：群组复制提供更好的冗余性、自动恢复以及写入扩展。 MySQL InnoDB Cluster：基于群组复制，提供了易于管理的API、应用故障转移和路由、易于配置，提供比群组复制更高级别的可用性。 MySQL NDB Cluster：容易与MySQL InnoDB Cluster混淆