分布式算法

限流必然是很有价值的，在系统资源不足时面对外部世界的不确定性（突发流量，超预期的用户）而形成的一种自我保护机制。 但是价值感是很低的，因为99.99%的时候系统总是工作在安全线之下，甚至一年到头都碰不到一次撞线的机会。这就好比法律，它始终存在，但是大部分时候对于大多数人它几乎不存在，或者说感知不到它的存在。 一、限流的作用 由于API接口无法控制调用方的行为，因此当遇到瞬时请求量激增时，会导致接口占用过多服务器资源，使得其他请求响应速度降低或是超时，更有甚者可能导致服务器宕机。 限流(Rate limiting)指对应用服务的请求进行限制，例如某一接口的请求限制为100个每秒,对超过限制的请求则进行快速失败或丢弃。 限流可以应对： 热点业务带来的突发请求； 调用方bug导致的突发请求； 恶意攻击请求。 因此，对于公开的接口最好采取限流措施。 二、为什么要分布式限流 当应用为单点应用时，只要应用进行了限流，那么应用所依赖的各种服务也都得到了保护。 但线上业务出于各种原因考虑，多是分布式系统，单节点的限流仅能保护自身节点，但无法保护应用依赖的各种服务，并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。 而如果实现了分布式限流，那么就可以方便地控制整个服务集群的请求限制，且由于整个集群的请求数量得到了限制，因此服务依赖的各种资源也得到了限流的保护。 三、限流的算法

分布式算法 转自： https://blog.51cto.com/alanwu/1431397 在分布式存储中面临的一个重要问题是如何在多个存储节点上分布数据。了解GFS之类文件系统的同学都知道可以采用元数据服务器（MS）的方式决定数据块在存储节点上的分布映射。采用元数据服务器方式可以很好的将数据和元数据分离，访问文件系统命令空间的时候，可以直接从元数据服务器上获取文件的映射信息。基于MS的分布式存储架构如下图所示： 基于元数据服务器的方式是分布式存储的经典架构，虽然看起来很完美，但是还是存在如下两大主要问题： 1，可扩展性受限于元数据服务器的能力。所有的元数据信息都集中在元数据服务器上面，所以，当Client想要获取元数据时就需要访问该服务器。因此，整体的带载能力（Client的个数）就受限于元数据服务器的能力。元数据服务器就是整个分布式系统的潜在瓶颈点。特别当Client访问小文件时，会产生大量的元数据信息，此时元数据服务器就会成为系统性能瓶颈。 2，元数据服务器是分布式系统中的单点故障点。一旦元数据服务器发生故障，整个分布式存储系统将无法正常工作，因此，元数据服务器的可靠性尤为重要。 总结起来，基于元数据服务器的分布式存储架构最大的问题在于可扩展能力和可靠性。而且这些问题的核心点都在于元数据服务器上。对此也有很多的系统优化手段，例如，针对元数据服务器影响系统可扩展性能力的问题

什么是负载均衡（Load balancing） 在网站创立初期，我们一般都使用单台机器对台提供集中式服务，但随着业务量越来越大，无论性能还是稳定性上都有了更大的挑战。这时候我们就会想到通过扩容的方式来提供更好的服务。我们一般会把多台机器组成一个集群对外提供服务。然而，我们的网站对外提供的访问入口都是一个的，比如www.taobao.com。那么当用户在浏览器输入www.taobao.com的时候如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡在做的事情。 当前大多数的互联网系统都使用了服务器集群技术，集群即将相同服务部署在多台服务器上构成一个集群整体对外提供服务，这些集群可以是Web应用服务器集群，也可以是数据库服务器集群，还可以是分布式缓存服务器集群等。 在实际应用中，在Web服务器集群之前总会有一台负载均衡服务器，负载均衡设备的任务就是作为Web服务器流量的入口，挑选最合适的一台Web服务器，将客户端的请求转发给它处理，实现客户端到真实服务端的透明转发。最近几年很火的「云计算」以及分布式架构，本质上也是将后端服务器作为计算资源、存储资源，由某台管理服务器封装成一个服务对外提供，客户端不需要关心真正提供服务的是哪台机器，在它看来，就好像它面对的是一台拥有近乎无限能力的服务器，而本质上，真正提供服务的是后端的集群。 软件负载解决的两个核心问题是： 选谁、转发

分布式设计与开发 CAP原理和最终一致性(Eventually Consistency) 分布式算法 [分布式Paxos算法] 分布式一致性Hash算法 轮循算法（Round Robin） Hash求余算法（Hash） 最少连接算法（Least Connection） 响应速度算法（Response Time） 加权算法（Weighted） 分布式消息 分布式发布订阅消息系统Kafka架构设计 分布式缓存 Redis 分布式 Memcached 分布式 分布式存储 分布式事务 【分布式事务系列一】提出疑问和研究过程 【分布式事务系列二】Spring事务管理器PlatformTransactionManager 【分布式事务系列三】Spring的事务体系 【分布式事务系列四】分布式事务的概念 【分布式事务系列五】jotm的分布式案例 【分布式事务系列六】jotm分布式事务源码分析 【分布式事务系列七】Atomikos的分布式案例 【分布式事务系列八】JTA深度历险-原理与实现 【分布式事务系列九】聊聊分布式事务 来源： oschina 链接： https://my.oschina.net/u/120166/blog/540071

每个大型网站都是由小变大的，在变大的过程中，几乎都需要经历单机架构、集群架构到分布式架构的演变。而伴随着业务系统架构一同演变的，还有各种外围系统和存储系统，比如关系型数据库的分库分表改造、从本地缓存到分布式缓存的过渡等。 在业务架构逐渐复杂的同时，保证系统的高性能、高可用、易扩展、可伸缩，使框架能有效地满足业务需要，是一个长远而艰巨的任务。本文介绍了五种相关的技术：分布式服务化架构、大流量的限流和削峰、分布式配置管理服务、热点数据的读写优化和数据库的分库分表。 值得注意的是，技术并不是越复杂越好，技术是为了更好地服务业务，只要能达到业务的需求，就是好的技术。简单说就是，即使你有实现复杂技术的能力，没有用户量和利润为基础，也难以落地实施。所以虽然下文中提到了一些框架，但是并不是每一种框架都需要你去亲自实践。很多时候，只是给你提供一个新的思路，一种新的方法，而至于是不是值得被实践，还需要得到业务和用户的考验。 文章目录 分布式服务化架构 集群和分布式 服务化架构，微服务和RPC 服务化架构的组成 服务的横向拆分 服务治理方案 总结 大流量的限流和削峰 分布式系统为什么要进行流量管制 限流方案 削峰方案 基于时间分片的削峰方案 基于异步调用的削峰方案 分布式配置管理服务 热点数据的读写优化 缓存技术 热卖商品的高并发读 基于Redis集群的多写多读方案

分布式快照 Distributed Snapshots: Determining Global States of Distributed Systems 这篇论文是Chandy和Lamport大神的作品，理论性非常强，没有具体应用的例子，读起来非常吃力。 我的能力有限，同时阅读这篇文章为了找到一种分布式系统做全局快照的方法，所以只对前面三章做了攻读。 如果想要找到一种算法实现分布式死锁检测、分布式数据库的全局快照，或者系统处于某个状态，都可以通过这个算法来解决。 论文链接： http://lamport.azurewebsites.net/pubs/chandy.pdf 1. 介绍 这篇论文想要介绍一个进程在分布式系统中可以确定一个全局状态，并且不中断计算(不影响业务)。分布式系统中的进程通过收发消息来通讯。 一个进程记录它自己的状态和收发的消息，也可以什么都不记录。 为了确定一个全局系统的状态，进程 p 必须召集其它合作进程记录它们的本地状态，然后发送记录的本地状态给 p 。 所有进程不可能在同一时刻记录本地状态，除非它们可以有一个共同的时钟。 这里要假设进程没有共同的时钟，也不共享内存。 其实这是大部分分布式系统的实现，不过即使在同一台机器上的进程，也不能保证访问同一个时钟的时间点是同一个时刻，没办法让进程在某个时刻静止。 所有机器在同时在某个时间点做某个事情也是不现实的

本文引用自 http://www.cnblogs.com/sunddenly/p/4033574.html 引言 　　Hadoop 集群当中 N 多的配置信息如何做到全局一致并且单点修改迅速响应到整个集群？ --- 配置管理 　　Hadoop 集群中的 namonode 和 resourcemanager 的单点故障怎么解决？ --- 集群的主节点的单点故障 分布式协调技术 　　在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调 度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问 题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内 容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 　　给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的

一、分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调 度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问 题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内 容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 图 1.1 分布式系统图 给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到我这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个 分布式系统 。 那我们接下来再分析一下，在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源，然后这三个物理分布的进程都要竞争这个资源，但我们又不希望他们同时进行访问，这时候我们就需要一个 协调器 ，来让他们有序的来访问这个资源

一、分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 图 1.1 分布式系统图 给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到我这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个 分布式系统 。 那我们接下来再分析一下，在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源，然后这三个物理分布的进程都要竞争这个资源，但我们又不希望他们同时进行访问，这时候我们就需要一个 协调器 ，来让他们有序的来访问这个资源

参考文章： 《In Search of an Understandable Consensus Algorithm》 https://raft.github.io/ http://thesecretlivesofdata.com/raft/ 这里有一个非常适合理解raft协议的 小动画 。 1.1.1 简介 概念： raft是一种用于管理log 复制的一致性协议，它和paxos有同样功能，但是比它简单容易理解。 功能： leader 选举、日志复制及安全问题。并且提供了强一致性。 1.1.2 原理 这里以3个节点为例 每个节点都有三种状态：leader、candidate、follower 每个组有三种行为：leader election、log replication、safety。 1） leader election 当启动三个节点时，都处在candidate状态（raft有时间机制，然后发送vote信息给其他节点），当超过一半时会变成candidate，其他两个节点的状态会变为follower。 所有客户端数据的交换都跟leader进行。 2） log replication log replication保证了数据在组中的一致性。log entry是这个的核心。 下图是过程 在第三步的时候，raft协议会使用append entries message心跳检测