分布式一致性

Paxos Paxos算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法。由于算法难以理解，起初并没有引起大家的重视，Lamport在1998年将论文重新发表到TOCS上，即便如此Paxos算法还是没有得到重视，2001年Lamport用可读性比较强的叙述性语言给出算法描述。 06年Google发布了三篇论文，其中在Chubby锁服务使用Paxos作为Chubby Cell中的一致性算法，Paxos的人气从此一路狂飙。 基于Paxos协议的数据同步与传统主备方式最大的区别在于：Paxos只需超过半数的副本在线且相互通信正常，就可以保证服务的持续可用，且数据不丢失。 Basic-Paxos Basic-Paxos解决的问题：在一个分布式系统中，如何就一个提案达成一致。 需要借助两阶段提交实现： Prepare阶段： Proposer选择一个提案编号n并将prepare请求发送给 Acceptor。 Acceptor收到prepare消息后，如果提案的编号大于它已经回复的所有prepare消息，则Acceptor将自己上次接受的提案回复给Proposer，并承诺不再回复小于n的提案。 Accept阶段： 当一个Proposer收到了多数Acceptor对prepare的回复后，就进入批准阶段

问题： 擅长的语言 项目中主要写前端还是后端 项目前端数据如何展示？是前后端分离吗 用到的框架？ 接触过SpringBoot吗 讲一下GC的理解 项目中如何保证事物 Java8的新特性 Volatile和Lock 项目中用到了哪些设计模式 如何保证分布式架构项目中的数据一致性 如何实时保证分布式架构项目中的数据一致性 算法：给一个整数n，代表n个左括号，和n个右括号，判断合法的排列组合有多少种？ 总结： get offer，最后两个问题，是问如何保证系统之间的数据一致性，和数据最终一致性。 数据最终一致性可以是t+1的一致性，比如一个招聘系统，可以开启一个定时任务，每天0点将数据推送到下游系统。即下游系统可以容忍数据延迟。 数据一致性就要求数据的实时一致性，比如通过MQ或者kafka发消息消费的方式，进行实时的数据传输。或者通过mysql中的bin log，来实现数据的复制。 算法题答得不是很好，当时给出的答案是全排列+栈的方式，可以用回溯法+剪枝的方法去做。 众安保险是腾讯、蚂蚁金服、平安保险三方控股的互联网+保险公司，也是很值得去的。但是要求先去实习，并且不能发校招offer，最后就没有去，比较遗憾。 来源： https://www.cnblogs.com/nedulee/p/11831625.html

一、算法背景 一致性哈希算法在1997年由麻省理工学院的Karger等人在解决分布式Cache中提出的，设计目标是为了解决因特网中的热点(Hot spot)问题，初衷和CARP十分类似。一致性哈希修正了CARP使用的简单哈希算法带来的问题，使得DHT可以在P2P环境中真正得到应用。 二、应用场景 现在一致性hash算法在分布式系统中也得到了广泛应用，分布式系统中涉及到集群部署，包括缓存Redis集群，数据库集群，我们在使用Redis的时候，为了保证Redis的高可用，提高Redis的读写性能，最简单的方式我们会做主从复制，组成Master-Master或者Master-Slave的形式，或者搭建Redis集群，进行数据的读写分离，类似于数据库的主从复制和读写分离。如下所示： 同样数据库中也是，当单表数据大于500W的时候需要对其进行分库分表，当数据量很大的时候（标准可能不一样，要看Redis服务器容量）我们同样可以对Redis进行类似的操作，就是分库分表。 假设，我们有一个社交网站，需要使用Redis存储图片资源，存储的格式为键值对，key值为图片名称，value为该图片所在文件服务器的路径，我们需要根据文件名查找该文件所在文件服务器上的路径，数据量大概有2000W左右，按照我们约定的规则进行分库，规则就是随机分配，我们可以部署8台缓存服务器，每台服务器大概含有500W条数据

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

http://www.cnblogs.com/edisonchou/ 《大型网站技术架构》读书笔记之六：永无止境之网站的伸缩性架构 此篇已收录至 《大型网站技术架构》读书笔记系列目录 贴，点击访问该目录可获取更多内容。 首先，所谓网站的伸缩性，指 不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力 。在整个互联网行业的发展渐进演化中，最重要的技术就是 服务器集群 ，通过不断地向集群中添加服务器来增强整个集群的处理能力。 一、网站架构的伸缩性设计 1.1 不同功能进行物理分离实现伸缩 　　（1）纵向分离：将业务处理流程上得不同部分分离部署，实现系统的伸缩性； 　　（2）横向分离：将不同的业务模块分离部署，实现系统的伸缩性； 1.2 单一功通过集群规模实现伸缩 　　使用服务器集群，即将相同服务部署在多台服务器上构成一个集群整体对外提供服务。具体来说，集群伸缩性又分为应用服务器集群伸缩性和数据服务器集群伸缩性。这两种集群对于数据状态管理的不同，技术实现也有很大的区别。 　It is said that 当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车 。 二、应用服务器集群的伸缩性设计 2.1 应用服务器那点必须知道的事儿 　　（1）应用服务器应该被设计成 无状态 的，即应用服务器不存储请求上下文信息；构建集群后

一致性模型 弱一致性 最终一致性 DNS (Domain Name System) Gossip (Cassandra的通信协议) 强一致性 同步 Paxos Raft (multi-paxos) ZAB (multi-paxos) 强一致性要解决的的问题 数据不能存在单点上(安全) 分布式系统对fault tolorence 的一般解决方案是state machine replication(状态机复制) state machine replication 的 共识(consensus) 算法。 paxos 其实是一个共识算法 系统的最终一致性, 不仅需要达成共识, 还会取决于 client的行为。 假设x为命令 Client --(x)--> Consensus Module x stored in that server's own log(x 存储在该服务器自己的日志中) Consensus Module --(x)--> Other servers each of them records the command in their own log(每台服务器都将x存储到自己的日志中) 强一致性算法: 主从同步 Master 接受写请求 Master复制日志到slave Master等待, 直到所有从库返回 可能出现的问题: 一个节点失败, Master阻塞,

转自： https://blog.csdn.net/pengjunlee/article/details/86517935 1998年，加州大学的计算机科学家 Eric Brewer 提出了分布式系统的三个指标： C：Consistency，一致性。在分布式系统中的所有数据备份，在同一时刻具有同样的值，所有节点在同一时刻读取的数据都是最新的数据副本（all nodes see the same data at the same time）。 A：Availability ，可用性，好的响应性能。完全的可用性指的是在任何故障模型下，服务都会在有限的时间内处理完成并进行响应（Reads and writes always succeed）。 P：Partition Tolerance ，分区容错性，即分布式系统在遇到某些节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。分区容错性要求一个分布式系统中有某一个或者几个节点故障时，其他剩下的节点还能够正常运转并对外提供服务，对于用户而言并没有什么体验上的影响。 Eric Brewer 指出任何分布式系统只可同时满足CAP三个指标中的两个，无法三者兼顾，这个结论就叫做 CAP 定理。 　　 定理解读 分布式的服务化系统都需要满足分区容忍性，那么我们必须在一致性（C）和可用性（A）之间进行权衡。在网络分区故障发生时

转自： https://www.cnblogs.com/rjzheng/p/9096228.html 引言 为什么写这篇文章? 博主的 《分布式之消息队列复习精讲》 得到了大家的好评，内心诚惶诚恐，想着再出一篇关于复习精讲的文章。但是还是要说明一下，复习精讲的文章偏面试准备，真正在开发过程中，还是脚踏实地，一步一个脚印，不要投机取巧。 考虑到绝大部分写业务的程序员，在实际开发中使用redis的时候，只会setvalue和getvalue两个操作，对redis整体缺乏一个认知。又恰逢博主某个同事下周要去培训redis，所以博主斗胆以redis为题材，对redis常见问题做一个总结，希望能够弥补大家的知识盲点。 复习要点? 本文围绕以下几点进行阐述 1、为什么使用redis 2、使用redis有什么缺点 3、单线程的redis为什么这么快 4、redis的数据类型，以及每种数据类型的使用场景 5、redis的过期策略以及内存淘汰机制 6、redis和数据库双写一致性问题 7、如何应对缓存穿透和缓存雪崩问题 8、如何解决redis的并发竞争问题 正文 1、为什么使用redis 分析 :博主觉得在项目中使用redis，主要是从两个角度去考虑: 性能 和 并发 。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等

转自： https://www.cnblogs.com/rjzheng/p/9619855.html#4365629 引言 大家在面试的时候，是否遭遇过，面试官询问 你们是如何进行数据库优化的? 那这个问题应该怎么答呢？其实写这个题材的原因是我这几天看到各公众号转的一篇数据库调优的知识（不上链接了），我就稍微翻了几下，上面动不动就来说要对数据库进行 水平拆分 ，我就想反问各位读者，你们几个人经历过 水平拆分 ?现在很多文章，实践性实在太差，只能说纯理论分析。 这篇文章最早来自知乎的一个提问，我在其基础上完善了一下。 第一阶段 优化sql和索引 这才是调优的第一阶段啊， 为什么呢？ 因为这一步成本最低啊，不需要加什么中间件。你没经过索引优化和SQL优化，就来什么 水平拆分 ，这不是坑人么。 那 步骤 是什么样呢?我说个大概 (1)用慢查询日志定位执行效率低的 SQL 语句，开启慢查询日志方式： (2)用 explain 分析 SQL 的执行计划 (3)确定问题，采取相应的优化措施，建立索引啊，等 我就不举例了，因为如何优化SQL的文章，一抓一大把，再贴过来，读者看着也累。 第二阶段 搭建缓存 在优化sql无法解决问题的情况下，才考虑搭建缓存。毕竟你使用缓存的目的，就是将复杂的、耗时的、不常变的执行结果缓存起来，降低数据库的资源消耗。 这里需要 注意 的是:搭建缓存后

传统数据库中的特性为： 4个，ACID：A （Atomicity） 原子性 C （Consistency） 一致性 I （Isolation） 独立性 D (druability) 持久性 NOSQL的CAP特性： C （Consistency） 强一致性：事物提交时数据不能发生变化 A （Availability） 可用性 P （Partition） 分区容错性 CAP理论就是说：很难同时满足CAP三条特性，正常只能较好的满足其中的两条。 在Oracle数据库中：满足CA两条特性。 在网站架构中：会选择满足AP两条，因为强一致的需求并不是一定需要的，比如说一个商品有100个人浏览和105个浏览，这对于用户来说不是非常重要。 在分布式存储系统中：由于当前网络问题，肯定会出现延迟丢包等问题，所以P分区容错性是必须满足的，对于存储系统，强一致性也是必须要满足的，所以最终的选择是AP。 BASE原理： BA （Basically Availability） 基本可用 S （Soft state） 软状态 E （Eventually consistent） 最终一致性 这个原理就是指某些时刻，我们可以去放松一些数据的一致性去换取系统的性能上的加强。 来源： https://www.cnblogs.com/lockXie/p/11784211.html