可用性

使用消息队列的好处以及使用场景还有引发的问题 1.流量削峰,用于短时间高并发流量情况,如秒杀活动,双11活动 在传统模式中,用户请求到达服务器后,再由服务器将数据写入数据库,在高并发情况下,流量暴增,数据库写入压力剧增,造成服务器响应时间漫长. 使用消息队列后,服务器将数据发送到消息队列服务器,然后将响应结果返回给用户,消息队列的数据由其消费者去读取并异步的写入到数据库.通过拉长数据处理时间来减少数据库瞬时压力达到流量削峰的目的 2,服务解耦 假设有这样一个场景, 服务A产生数据, 而服务B,C,D需要这些数据, 那么我们可以在A服务中直接调用B,C,D服务,把数据传递到下游服务即可 但是,随着我们的应用规模不断扩大,会有更多的服务需要A的数据,如果有几十甚至几百个下游服务,而且会不断变更,再加上还要考虑下游服务出错的情况,那么A服务中调用代码的维护会极为困难 使用消息队列后, A服务只需要向消息服务器发送消息,而不用考虑谁需要这些数据;下游服务如果需要数据,自行从消息服务器订阅消息,不再需要数据时则取消订阅即可 3.异步调用 考虑定外卖支付成功的情况 支付后要发送支付成功的通知,再寻找外卖小哥来进行配送,而寻找外卖小哥的过程非常耗时,尤其是高峰期,可能要等待几十秒甚至更长 这样就造成整条调用链路响应非常缓慢 而如果我们引入消息队列,订单数据可以发送到消息队列服务器

一、引子 在上一篇文章中，我和你介绍了 binlog 的基本内容，在一个主备关系中，每个备库接收主库的 binlog 并执行。 正常情况下，只要主库执行更新生成的所有 binlog，都可以传到备库并被正确地执行，备库就能达到跟主库一致的状态，这就是最终一致性。 但是，MySQL 要提供高可用能力，只有最终一致性是不够的。为什么这么说呢？今天我就着重和你分析一下。 这里，我再放一次上一篇文章中讲到的双 M 结构的主备切换流程图。 图 1 MySQL 主备切换流程 -- 双 M 结构 二、主备延迟 主备切换可能是一个主动运维动作，比如软件升级、主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电。 接下来，我们先一起看看主动切换的场景。 在介绍主动切换流程的详细步骤之前，我要先跟你说明一个概念，即“同步延迟”。与数据同步有关的时间点主要包括以下三个： 1. 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1; 2. 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2; 3. 备库 B 执行完成这个事务，我们把这个时刻记为 T3。 所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。 你可以在备库上执行 show slave status 命令，它的返回结果里面会显示

一、Eureka原理 1、架构图 首先来看eureka的官方结构图 　　所有应用作为Eureka Client和Eureka Server交互，服务提供者启动时向Eureka Server注册自己的IP、端口、提供服务等信息，并定时续约更新自己的状态。 　　服务消费者通过Eureka Server发现得到所需服务的提供者地址信息，然后向服务提供者发起远程调用。 　　为了保证Eureka注册中心的高可用，可以集群部署，其中一个节点信息又更新时通知其他Server节点，不同节点的Eureka通过Replicate进行数据同步。 2、基本原理 在Eureka响应的过程中，有三个角色，分别是Eureka、服务提供者、服务消费者； 在服务启动后，服务提供者向Eureka注册自己的信息，如调用地址、提供服务信息等 Eureka为服务注册中心，向外暴露自己的地址，负责管理、记录服务提供者的信息，同时将符合要求的服务提供者地址列表返回服务消费者 服务消费者向Eureka订阅服务，表达自己的需求，然后得到服务提供者消息，远程调用即可 Eureka包含两个组件：Eureka Server和Eureka Client，作用如下: Eureka Client是一个Java客户端，主要用来简化和Eureka Server的交互 Eureka Server提供服务发现的能力，各个微服务启动时，通过Eureka

区块链系统是一个分布式系统，而分布式系统的首要问题是一致性的保障。 一致性 　　定义：一致性（consistency），早期也叫agreement，是指对于分布式系统中的多个服务节点，给定一系列操作，在约定协议的保障下，试图使得他们对处理结果达成“某种程度”的认同。 一致性并不代表结果正确与否，而是系统对外呈现的状态一致与否；例如，所有节点都达成失败状态也是一种一致。 　　将可能引发不一致的并行操作进行串行化 是现代分布式系统处理一致性问题的的基础思路。 　　事件的先后顺序十分重要，这也是解决分布式系统领域很多问题的核心秘诀：把多件事情进行排序，并且这个顺序还得是大家都认可的。 共识算法 　　共识（consensus）在很多时候会与一致性（consistency）术语放在一起讨论。严谨地讲，两者的含义并不完全相同。 　　 一致性 往往指分布式系统中多个副本对外呈现的数据的 状态 。 共识 则描述了分布式系统中多个节点之间，彼此对某个状态达成一致结果的 过程 。因此，一致性描述的是结果状态，共识则是一种手段。达成某种共识并不意味着就保障了一致性。 　　在实践中，要保障系统满足不同程度的一致性，核心过程往往需要通过共识算法来达成。共识算法解决的是对某个提案（proposal） 大家达成一致意见的过程 。 提案的含义在分布式系统中十分宽泛，比如多个事件发生的顺序、某个键对应的值

在弄清楚这个问题之前，我们先了解一下什么是分布式的CAP定理。 根据百度百科的定义，CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。 一、CAP的定义 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体

本人免费整理了Java高级资料，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程，一共30G，需要自己领取。 传送门： https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q 目录 一、分布式锁 数据库的唯一索引 Redis 的 SETNX 指令 Redis 的 RedLock 算法 Zookeeper 的有序节点 二、分布式事务 2PC 本地消息表 三、CAP 一致性 可用性 分区容忍性 权衡 四、BASE 基本可用 软状态 最终一致性 五、Paxos 执行过程 约束条件 六、Raft 单个 Candidate 的竞选 多个 Candidate 竞选 数据同步 一、分布式锁 在单机场景下，可以使用语言的内置锁来实现进程同步。但是在分布式场景下，需要同步的进程可能位于不同的节点上，那么就需要使用分布式锁。 阻塞锁通常使用互斥量来实现： 互斥量为 0 表示有其它进程在使用锁，此时处于锁定状态； 互斥量为 1 表示未锁定状态。 1 和 0 可以用一个整型值表示，也可以用某个数据是否存在表示。 数据库的唯一索引 获得锁时向表中插入一条记录，释放锁时删除这条记录。唯一索引可以保证该记录只被插入一次，那么就可以用这个记录是否存在来判断是否存于锁定状态。

决定share一下我的cassandra学习成果，写一些博客，跟大家共同分享一下，准备写10篇文章，内容分别涉及 分布式存储概述及CAP, 数据模型, 分区器， 副本机制， 存储机制， 数据读写删， 最终一致性， gossip, cassandra的实际应用， 学习总结。 先写第一篇，先说咋理解分布式。 这术语解释起来拗口，举个例子就比较好理解了。 比如说参与cloudtask这个项目的人，有好几拨，有王薇 team，有徐超 team， 有韶涵 team， 有田萌 team, 有红艳 team. 为啥分成几拨人来做呢？ 为啥不是james大侠（CTO）一力承担？ 因为james智慧再高超，本领再强大，也没有办法一个人处理所有事情。 计算机里有两个词，一个叫纵向扩展，一个叫横向扩展，james加班加点看代码，这个是纵向扩展，这个扩展是有限的，扩展到24个小时，就到头了。 因为此，较为可行的办法是横向扩展，就是如前所说的，分成几拨人来做，这就是分布式了。 分布式的优点是大大的，最明显的就是可以同时处理很多事情，可以同时响应很多请求。 分布式万岁！ 且慢！ 啥东西也不是光有优点，分布式的缺点也是大大的。 这缺点，其实很容易想到，刚才的例子中，工作分了几拨人来做，每人都是James吗？ ＮＯ。每人都会有自己的认知，每人的认知都不同，分成５波人来做，５波人就有５个认知，所以要怎么办呢？ 沟通

虚拟化和云计算机近几年来一直都很热，而且笔者在网上查询了很多资料，由于vSphere的整套解决方案，价格的确不菲，且实验环境搭建起来比较困难，所以网上也很难找到相关的学习资料。现将笔者的学习笔记贡献出来给大家分享，仅供各位博友们参考，同时难免有疏漏之处，还请各位不吝赐教。 相信很多同事都用过vmware workstation这款产品，可以使我们安装很多虚拟机，但是vmware的核心产品远非局限于workstation。vSphere是VMware推出的基于云的新一代数据中心虚拟化套件，提供了虚拟化基础架构、高可用性、集中管理、监控等一整套解决方案，目前最新版本为vSphere 5.0。现在让我们来了解一下这款神奇的产品吧。 一、vmware vSphere兼容性判断 如何判断当前的硬件设备是否支持vSphere? 主要影响的硬件，CPU，网卡 HCL兼容性网站支持的CPU列表查询网址： 二、VMware vSphere 组件和功能 VMware vSphere 包括下列组件和功能。 VMware ESXi vSphere去掉了原来的ESX，因保留了ESXi。一个在物理服务器上运行的虚拟化层，它将处理器、内存、存储器和资源虚拟化为多个虚拟机。 VMware vCenter Server 配置、置备和管理虚拟化 IT 环境的中央点。它提供基本的数据中心服务，如访问控制

什么是队列镜像 默认情况下，RabbitMQ集群中队列的内容位于单个节点（声明该队列的节点）上。 这与交换和绑定相反，交换和绑定始终可以被视为在所有节点上。 可以选择使队列 跨多个节点 进行 镜像 。 每个镜像队列由一个 主服务器 和一个或多个 镜像组成 。 主节点托管在一个通常称为主节点的节点上。 每个队列都有其自己的主节点。 给定队列的所有操作都首先应用于队列的主节点，然后传播到镜像。 这涉及排队发布，向消费者传递消息，跟踪 来自消费者的确认 等。 队列镜像意味着 节点的集群 。 因此，不建议在WAN中使用它（当然，客户端仍然可以根据需要进行远近连接）。 发布到队列的消息将复制到所有镜像。 消费者连接到主服务器，无论他们连接到哪个节点，镜像都会丢弃已在主服务器上确认的消息。 因此，队列镜像可提高可用性，但不会在节点之间分配负载（所有参与节点均完成所有工作）。 如果承载队列主服务器的节点发生故障，则最早的镜像将在同步后提升为新的主服务器。 根据队列镜像参数，也可以升级 不同步的 镜像。 通常有多个术语用于标识分布式系统中的主副本和辅助副本。 本指南通常使用“主”来指代队列的主副本，并使用“镜像”来指代辅助副本。 但是，RabbitMQ CLI工具在历史上一直使用术语“从属”来引用次级。 因此，该术语仍显示在CLI工具的列名中，以实现向后兼容，但最终将被替换。 镜像的配置方式 使用

说在前面 我曾不止一次听说过这句话： “十个女人无法在一个月内生出孩子” 我明白这句话的意思，用来形容我们的开发工作需要循序渐进，没有办法简单的增加人员就能加快研发速度。 这句话也经常被用于反驳产品经理或者老板，试图让他们明白我们内心所表达的观点，老实说我也说过这样的话，当时还觉得挺有道理，现在想来可能有些一厢情愿了。 没错，在现实世界中，当然不可能在一个月内生出孩子，但我们毕竟是做产品写代码的，而不是真的要去生孩子，所以这种说法未免有点偷换概念。 我并不是较真，如果只是想让产品经理明白我们所要表达的观点，我们完全可以用其他的比喻，如实反馈存在的困难与问题即可。 言归正传，这句话与本文有什么关系呢？本文想要就“并发”所带来的问题进行探讨，相信看完后你会对此有一个感觉。 与我之前写的几篇文章一样，并发一词在本文中所表达的意思是： “在分布式环境下，超过一个线程同时对同一个状态进行访问和变更所导致的一致性问题和可用性问题” 问题的根源：状态 我无法给出一个百分比数据用以说明到底有多少后端应用程序在使用数据库，但我想国内涉及到增删查改之类的各种“管理系统”应该不在少数。 说到底，增删改查是落地，而怎么落地则取决于业务的需要，也就是说，业务规则以及流程表达了我们的逻辑，但终究离不开柴米油盐（增删改查）。 那么什么是状态？ 它可以是文件，也可以是数据库，可以是一个变量，也可以是缓存