2021.1.15 主从复制、持久化备份、过半投票、区块链、p2p

本文主要是介绍2021.1.15 主从复制、持久化备份、过半投票、区块链、p2p，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

zk的过半投票——leader选举和事务提议选举

在这里插入图片描述

redis的持久化（快照RDB和事务记录AOF）和主从复制

ZooKeeper的实现原理

分布式文件系统（DFS：distributed file system）

使用户更加容易访问和管理物理上跨网络分布的文件,用户在访问文件时不需要知道它们的实际物理位置，即分布在多个服务器上的文件在用户面前就如同在网络的同一个位置。
通过DFS，可以将同一网络中的不同计算机上的共享文件夹组织起来，形成一个单独的、逻辑的、层次式的共享文件系统。
案例如：DFS是一个树状结构，包含一个根目录和一个或多个DFS链接。要建立DFS共享，必须首先建立DFS根，然后在每一个DFS根下，创建一个或多个DFS链接，每一个链接可以指向网络中的一个共享文件夹
比特币挖矿技术：分布式数据存储、点对点传输、共识机制、加密算法…相关技术的分析
上面的相关技术可能涉及：数据持久化和投票；（1）zk集群的投票原理（选举leader 和事务提议选举）；（2）redis数据持久化的两种方式（RDB和AOF）
数据持久化，redis和zookeeper中通常两种方式：快照方式，将内存中数据备份（redis中dump.rdb文件，可以在任何节点目录下，会自动加载输入）、事务记录的持久化方式（redis中改变系统状态的事务行为作为记录，所谓事务请求是指会改变集群状态的请求），即将事务状态改变的操作行为（指令）记录下来，AOF持久化是将创建数据而执行的命令写入到aof文件末尾，在恢复时需要从头到尾执行一遍写可以恢复所有数据。
投票过半原则——leader选举和事务提议投票；（1）zk集群的投票原理（选举leader 和事务提议选举）；

zk的选举

Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。

zookeeper本身是一个基于文件系统的目录节点的数据存储，但是本质不是专门存储数据的，核心是维护和监控存储的数据的状态变化的；
然后基于数据的状态变化，然后达到基于数据的集群管理。 如节点一对应数据a，节点二对应数据b，节点三对应数据c，数据abc分别存储在
zk中，通过监控和维护数据abc，来管理和维护节点一，二，三。因此数据存储主要是DFS分布式文件系统的事，DFS的数据主要存储在磁盘上，而ZooKeeper数据是存储在内存上，所以数据量就不可能太大，
所以zookeeper主要是协调功能，并不是用来存储数据的。简单来说，干什么事存什么数据，ZooKeeper所实现的一切功能，都是由ZK节点的性质和该节点所关联的数据实现的，
至于关联什么数据那就要看你干什么事了。
例如：① 集群管理：利用临时节点特性，节点关联的是机器的主机名、IP地址等相关信息，集群单点故障也属于该范畴。② 统一命名：主要利用节点的唯一性和目录节点树结构。③ 配置管理：节点关联的是配置信息。④ 分布式锁：节点关联的是要竞争的资源。

zk和redis的持久化方式类似：内存数据的备份——快照方式（redis的RDB方式）、记录事务操作行为的备份——保存能够改变Zookeeper或者redis服务状态的操作的行为（如增删改操作记录）的方式。（redis的AOF方式）
zk集群具有高可用的特点；和选举原理分析
zk集群原理：需要在集群中为每个zk节点创建myid文件，其中设置一个Id，这个id就是在集群中识别各自节点的标识符奥！
zk集群中节点有三个角色： leader、follower、observer；
leader是zk集群中事务请求唯一的调度者和处理者；所谓事务请求是指会改变集群状态的请求；Leader根据事务ID可以保证事务处理的顺序性。 简单说：leader可以进行事务处理和调度操作 集群不算是中心化，因为集群中就算leader挂了，也会内部leader选举而产生新leader，所以高可用，即集群过半存活即可用的特性。
follower是zk集群中处理非事务请求，如果follower接收到客户端事务请求会将请求转发给leader服务器；参与leader选择和leader事务处理投票；如果集群中leader不可用，会变更自身状态并发起leader选举投票，有机会可能成为leader。
Observer和follower相似，可以处理非事务请求，将请求转发给leader，但是不会参与leader选举和leader事务处理投票的，Observer用于不影响集群事务处理能力的前提下提示集群的非事务处理能力。
zk集群中leader是非常重要的角色，所以leader是选举很重要；————选举机制：

选举机制：
不管是在集群启动时选举Leader还是集群运行中重新选举Leader。集群中每个Follower角色服务都是以下面的条件作为基础推选出合适的Leader，
一旦出现某个节点被过半推选，即某个节点被过一半的节点推选，那么该节点晋升为Leader。（1）选举投票必须在同一轮次中进行，如果是不同轮次的选举，不会采纳的。
（2）数据最新的节点优先成为leader；—— 通过每个节点上的事务ID判定，事务ID越大任务节点数据越接近leader的数据，自然成为最新的leader。
（3）每个节点上事务ID相同的时候，节点id最大有优势，即server.id值大的优先成为leader。zk集群的节点并非越多越好节点越多，使用的资源越多节点越多ZooKeeper节点间花费的通讯成本越高，节点间互连的Socket也越多。影响ZooKeeper集群事务处理；        节点越多，造成脑裂的可能性越大细节一：
server.1=localhost:2881:3881      
其中server.1表示当前zk节点的id， ip表示当前zk节点所在机器的ip， 
2881表示集群的zk间非选举通讯端口， 3881表示zk集群节点间选举通讯端口细节二：
集群中投票：  ——  过半原则：集群中投票结果操作集群总数一半，便可以安全往下处理后续事务了。
（1）leader选举投票：  假设有3个节点组成ZooKeeper集群，这时Leader挂了，需要投票选举Leader。当相同投票结果过半后Leader选出。（2）事务提议投票：集群收到事务请求，然后leader来处理，接着leader会给所有的follower发起创建事务的提议，当收到follower一半的反馈后，
leader会继续给所有follower发起commit，就完成了事务请求的操作过程。

过半原则—— zk中有很多类型的投票： leader选举投票、事务提议投票；这些投票都依赖过半原则，就是zk任务投票结果超过集群总数的一半，就可以安全的处理后续事务了。
事务提议投票过半—— zk集群中，客户端请求添加一个节点，leader接收到该添加事务后，会给所有follower发起创建节点的提议投票，如果leader收到超过集群一半数量的反馈，继续给所有follower发送commit的指令，此时leader认为集群中过半的节点同意且同步了事务的操作了，这样就算自己挂掉集群也是安全的。
leader重新选举基于过半投票原理的过程： 有三个节点的集群（server.1、server.2、server.3）。注意选举leader过程中，每个follower的行为有：（1）变更自身的票、（2）发起投票、（3）接收其他follower发来的票，（4）将接收到的票和自身票pk（比较两个提议的事务id及server.id）、（5）pk结果决定是否变更自身的票和再次发起投票。注意：自身的票和发起的投票是不同的两个概念奥！！
首先——状态变更：假设server2是leader，而且挂了，哪去其他节点会变更自身状态为LOOKING，变更自身投票，投票内容是自身节点的事务ID和server.id，以（事务ID，server.id）表示；如加上server1的事务id是10，变更的自身投票就是（10,1）；server3事务id是8，那么变更自身的投票就是（8,3）；
接着—— 首轮投票：将变更的投票发给集群中所有的follower节点，如server1将（10,1）发给集群中所有follower，包括它自身，server3也是一样，将（8,3）发给所有follower。此时server1收到了（10,1）和（8,3）两个投票，server3将收到（8,3）和（10,1）两个投票；
投票pk——每个follower节点除了发起投票外，还接收其他follower的投票，并与自己的投票pk，pk结果决定是否要变更自身状态并再次投票。server1来讲，有（10,1）和（8,3）两个，与自身变更投票pk发现没有自身原本的要大，所以维持自身投票不变； server3收到（10, 1）和（8, 3），但是自身变更状态的票是（8,3），没有（10,1）的事务id大，所以认为server1发来的投票要大，server3会变更自身投票，并将变更后的票发给集群中所有follower，
第二轮投票—— server3将自身手里的票变更为（10,1）后再次发给给集群所有follower，注意这时已经是第二轮投票了奥！投票必须是相同轮数的比较奥！此时server1和server3在第二轮只有server3发来的（10,1）的票，server1将接收到发来的票与自身票对比发现事务id一样，继续保持不变，server3收到（10,1）的票，和自身已经变更为（10,3）的票，比较事务id相同，所以也不变更了。自此server1和server3达成一致，不会再次发生一轮投票了奥！
.投票结果的分析：每个节点的投票结果存储在投票桶——map中，且每个follower的投票结果在桶内只记录一次，map投票桶中key是保存投票的来源节点server.id的，Vote是对应节点的投票信息，注意：每个节点都有一个map的自身的接收桶，里面存储的就是每个follower的投票结果，所以投票结果选哪个节点为leader，每个节点都可以通过自身节点的投票桶中可以得到的，由于每个节点向所有包括自身节点在内都发送投票信息，所以每个节点自身投票桶中内容是一样的，所以结果也都是从自己投票桶中发现的；每个节点在不同轮中收到某个节点变更自身的投票情况，都会一轮一轮更新这个接收桶。所以投票桶中存储了所有follower节点的投票并且是最后一次的投票结果。

上面第一张是第一轮投票server1和server3中投票桶的所有follower节点的投票情况，然后节点内票数会相互pk，server3发现自身票没有server1的大，所以会变更自身投出的票情况，即server3的投票内容变成了（10,1）；由于server3手里的票发生了变更，所以会进行第二轮广播投票，第二轮中server3向所有follower节点发起的投票就变成（10,1），最后server1和server3的投票桶中来源节点server3的投票内容就变成了（10,1）了，自此桶内发现各个节点的投票内容过半选（10,1）这个票，表示节点1中事务id为10，记录的事务最多，所以leader是server1，server3变更为follower。

主从复制

上面分析了zk的过半投票的原理，那么主从复制和数据持久化只了解redis的方式。
17. redis的主从复制的原理：集群中主会有数据集的版本id（replication ID，这是一个伪随机数，用来把标识给定的数据集的），同时还有一个此版本数据集的发送多少字节的复制偏移量。简单说就是可以通过一对给定的replication ID、offset来标识一个master的数据集版本。
17. 从机同步主机的方式——当从连接到主时，会使用sync命令来发送自身记录的旧的master replication ID和它们至今为止处理的偏移量；通过这种方式，master能够仅发送slave所需的增量部分，从而是发送的io压力减小。但是如果master不知道从机的数据集的版本对记录，会进行全量重同步，这种情况下，slave会的到一个完整的数据集副本。
18.

区块链和p2p

p2p本质是一种分布式应用架构，一种对等技术模型的在应用层形成的一种网络形式（对等网络）；简单说，就是网络的参与者共享他们所拥有的一部分资源（处理。存储、网络连接）能力，这些资源可以通过网络被其他对等节点直接提供服务和内容，而无需经过中间实体。这样的网络中参与者既是资源、服务、内容的提供者，也是获取者。
至于区块链的诞生，则要追溯2008年，那年10月份，一个在网上化名为中本聪的人发表了一篇技术论文：《比特币白皮书：一种点对点的电子现金系统》，那个时候，还没有区块链这个概念。
比特币只是基于区块链这个技术，技术大牛不断丰富完善比特币系统，慢慢的他们发现，为比特币而设计的底层核心数据结构，是可以抽象出来的，就这样，区块链诞生了。
其实，区块链除了比特币的底层数据结构这一“身份”，还有一个前提，那就是P2P，对等网络；例如中本聪发表的论文就是基于点对点的现金系统。
作为区块链基石的此P2P并非彼P2P，而是指对等网络；要想说明白对等网络，得先说一说中本聪白皮书抛出的一个问题：需要第三方支持的点对点电子现金支付系统是没有价值的
对等网络因为全网无特殊节点，每个节点都可以提供全网所需的全部服务，任何一个节点垮掉，都不会对整个网络的稳定性构成威胁，所以是非常安全的。
区块链，正是以对等网络为组网模型的一种系统，可以说，对等网络是区块链系统的重要基石。用学术一点的话来说，区块链是一种去中心化的分布式记账系统。通俗一点说，区块链是一种全民参与记账的方式，系统中每个人都可以进行记账，每个人记的账都会发给系统的内其他人备份，这样系统中每个人都有了一本完整的账本，这就是去中心化。因为每个人都有一套完整账本，如果有人想作弊，一定要同时修改超过半数的数据，这种做法代价极高，导致几乎不可能，所以区块链系统数据会变得非常安全，数据几乎不可更改。
区块链的去中心化、安全、共享透明、高效、低成本等特征使得其应用范围非常广，比如金融服务、合同契约、慈善公益、物联网等，相信区块链将在未来改变很多行业的面貌。


区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、
利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式

区块链主要技术包括：分布式数据存储、点对点传输、共识机制、加密算法；主从复制、持久化备份、过半投票

区块链：狭义来讲，
区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构， 并以密码学方式保证的不可篡改和不可伪造的分布式账本。广义来讲，
区块链技术是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、
利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算方式。区块链主要技术包括：
（1）分布式数据存储： 去中心化的数据库，数据是保存在许多节点上的，这样虽然透明，但是安全呀，因为数据的修改需要过半才可完成，即以
大多人同意才可以修改数据，那么共识机制是如何制定的。
（2）点对点传输： 网络中参与者都是对等的，那么共享资源的网络是基于什么协议和规则的；
（3）共识机制：而去中心化数据库就像一个公共帐本，所有人都能查看，但没人能私自修改以往数据，因为它不可能修改分散在其他人机器上的数据库。在某个数据与其它数据库不一致时，则以大多数一致的为准，这就是所谓的“共识机制”。
（4）加密算法：区块链中行为（交易的发生）产生，会有一串加密算法来映射生成一个数据块，每个数据块就是包含了一次（比特币网络交易的信息）
行为。
区块链—— 交易信息时如何通过加密算法来转为数据块的，然后这些块如何形成一条链的过程。第三个叫做共识机制，就是所有记账节点之间怎么达成共识，去认定一个记录的有效性，这既是认定的手段，也是防止篡改的手段。
区块链提出了四种不同的共识机制，适用于不同的应用场景，在效率和安全性之间取得平衡。区块链的共识机制具备“少数服从多数”以及“人人平等”的特点，其中“少数服从多数”并不完全指节点个数，也可以是计算能力、股权数或者其他的计算
机可以比较的特征量。“人人平等”是当节点满足条件时，所有节点都有权优先提出共识结果、直接被其他节点认同后并最后有可能成为最终共识结果。哈希算法（摘要算法）：将任意长度的输入通过散列函数转换成固定长度的输出，输出就是散列值；任意长度的输入有一丁点变化，得到的散列
值就是不同的；所以哈希算法通常用于数据完整性的校验和密码验证； 最常见就是md5 信息摘要算法，md5算法是将不定长度的信息，输出为
固定长度的128bit的一种算法；用于检验下载或者密码等其他数据的完整性。常见的哈希算法有MD5、SHA1、SHA256、SHA512、NTLM等
哈希函数特点： 两个散列值不同，则输入一定不同、但是两个散列值相同，输入可能相同，当然也可能不同、输入有任何一丁点变化，对应的输出
散列值一定完全不同。 且通常哈希函数是一种快速收敛的算法，从输入到输出的计算非常快，迅速收敛数值，无须消耗巨大计算资源，而从输出到
输入几乎不可行，基于这些优秀的特性，哈希函数得到广泛的应用，人民币上的冠字号码也由哈希算法产生的。加密算法：使用密码对明文数据进行处理变成不可读的密文，跟哈希算法不同的是，加密算法是完全可逆的，哈希算法是不可逆的；
加密算法又分成对称加密算法及非对称加密算法，二者主要的区别在于如何使用密钥上，
对称加密算法使用同一个密码进行加解密，且常用于体积较大的数据加密。
非对称加密算法使用公钥及私钥对进行加解密，使用公钥加密的密文只能通过私钥解密，反过来使用私钥加密的密文则只能通过公钥解密，
非对称加密的运算成本很高，因此一般只用于身份验证及密码交换。 上面编码、哈希、加密算法为啥不能统称为加密算法？   ********     判断一个算法是否是加密算法要看它有没有加解密机制     *******
首先是否可逆：  编码和对称和非对称加密算法都是可逆的，而哈希算法是不可逆的。
其次判断是否有密码：  编码和哈希算法都不使用密码，而对称和非对称都使用密码

编码、哈希、加密算法（对称和非对称加密）的分析
使用密码对可读的原始数据进行处理并得到不可读密文的算法，跟哈希算法不同的是，加密算法是完全可逆的，只要提供密码及密文就可以通过解密获得明文。
比特币挖矿技术：分布式数据存储、点对点传输、共识机制、加密算法…相关技术的分析
上面的相关技术可能涉及：数据持久化和投票；（1）zk集群的投票原理（选举leader 和事务提议选举）；（2）redis数据持久化的两种方式（RDB和AOF）
数据持久化——redis和zookeeper中通常两种方式：快照方式，将内存中数据备份（redis中dump.rdb文件，可以在任何节点目录下，会自动加载输入）、事务记录的持久化方式（redis中改变系统状态的事务行为作为记录，所谓事务请求是指会改变集群状态的请求），即将事务状态改变的操作行为（指令）记录下来，AOF持久化是将创建数据而执行的命令写入到aof文件末尾，在恢复时需要从头到尾执行一遍写可以恢复所有数据。
投票过半原则——leader选举和事务提议投票；

这篇关于2021.1.15 主从复制、持久化备份、过半投票、区块链、p2p的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！