SHA Study

Posted by Haiming on March 13, 2019

1.前言

也算是开始了正式的工作,这才发现计算机这个东西真的是越学东西越多,但是也越有趣吧。在学习Git的过程之中对于Snapshot机制有疑问,在上网查找的过程之中发现疑问越来越多,设计的概念,东西也越来越多。因此在这里做一个整理,记录一下每天收获。

2.RPC

RPC,全程Remote Process Call, 是用来解决服务器集群之中分布式结构的各个子系统相互通信的问题。服务器的结构随着业务量的增长而出现不同的需求,下面的知乎回答说的很好,我就直接引用了 排版太烂请见谅……

作者:大闲人柴毛毛 链接:https://www.zhihu.com/question/20004877/answer/282033178 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

下面就正经解释下三种结构的区别吧~单机结构我想大家最最最熟悉的就是单机结构,一个系统业务量很小的时候所有的代码都放在一个项目中就好了,然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。那么,单机结构有啥缺点呢?我想缺点是显而易见的,单机的处理能力毕竟是有限的,当你的业务增长到一定程度的时候,单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式,往下接着看。集群结构集群模式在程序猿界有各种装逼解释,有的让你根本无法理解,其实就是一个很简单的玩意儿,且听我一一道来。 单机处理到达瓶颈的时候,你就把单机复制几份,这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”,所有节点构成了一个集群。每个节点都提供相同的服务,那么这样系统的处理能力就相当于提升了好几倍(有几个节点就相当于提升了这么多倍)。但问题是用户的请求究竟由哪个节点来处理呢?最好能够让此时此刻负载较小的节点来处理,这样使得每个节点的压力都比较平均。要实现这个功能,就需要在所有节点之前增加一个“调度者”的角色,用户的所有请求都先交给它,然后它根据当前所有节点的负载情况,决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展,当前的系统又支撑不住了,那么给这个集群再增加节点就行了。 但是,当你的业务发展到一定程度的时候,你会发现一个问题——无论怎么增加节点,貌似整个集群性能的提升效果并不明显了。这时候,你就需要使用微服务结构了。分布式结构先来对前面的知识点做个总结。从单机结构到集群结构,你的代码基本无需要作任何修改,你要做的仅仅是多部署几台服务器,每台服务器上运行相同的代码就行了。但是,当你要从集群结构演进到微服务结构的时候,之前的那套代码就需要发生较大的改动了。所以对于新系统我们建议,系统设计之初就采用微服务架构,这样后期运维的成本更低。但如果一套老系统需要升级成微服务结构的话,那就得对代码大动干戈了。所以,对于老系统而言,究竟是继续保持集群模式,还是升级成微服务架构,这需要你们的架构师深思熟虑、权衡投入产出比。OK,下面开始介绍所谓的分布式结构。分布式结构就是将一个完整的系统,按照业务功能,拆分成一个个独立的子系统,在分布式结构中,每个子系统就被称为“服务”。 这些子系统能够独立运行在web容器中,它们之间通过RPC方式通信。举个例子,假设需要开发一个在线商城。按照微服务的思想,我们需要按照功能模块拆分成多个独立的服务,如:用户服务、产品服务、订单服务、后台管理服务、数据分析服务等等。这一个个服务都是一个个独立的项目,可以独立运行。如果服务之间有依赖关系,那么通过RPC方式调用。这样的好处有很多:系统之间的耦合度大大降低,可以独立开发、独立部署、独立测试,系统与系统之间的边界非常明确,排错也变得相当容易,开发效率大大提升。系统之间的耦合度降低,从而系统更易于扩展。我们可以针对性地扩展某些服务。假设这个商城要搞一次大促,下单量可能会大大提升,因此我们可以针对性地提升订单系统、产品系统的节点数量,而对于后台管理系统、数据分析系统而言,节点数量维持原有水平即可。服务的复用性更高。比如,当我们将用户系统作为单独的服务后,该公司所有的产品都可以使用该系统作为用户系统,无需重复开发。

好了,那下面就是RPC的事情了。其主要分为三部分

  1. Call ID 映射:因为不同主机之间的内存空间不同,所以不可以直接使用指针。 其需要使用自己的进程ID,不同计算机上面的进程ID映射表可以不同,但是不同表的相同进程,其ID一定要相同。
  2. 序列化和反序列化:在不同服务器上面的进程之间肯定不可以使用内存来传递数据,且因为应用类型不同,其接受的数据类型,格式等等也都可能不同。在这种情况之下,发送的一方需要把数据序列化,传输这个序列,然后接受一方先将序列转化成自己接受的形式再进行处理。
  3. 网络传输:传过去就完事了

3. 散列算法

  1. 散列函数(英语:Hash function)又称散列算法、哈希函数,是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要,使得数据量变小,将数据的格式固定下来。该函数将数据打乱混合,重新创建一个叫做散列值(hash values,hash codes,hash sums,或hashes)的指纹。散列值通常用一个短的随机字母和数字组成的字符串来代表。好的散列函数在输入域中很少出现散列冲突。在散列表和数据处理中,不抑制冲突来区别数据,会使得数据库记录更难找到。

  2. 散列碰撞:不同的输入在同一个散列函数处理之后得到相同的输出.只要尝试空间足够大,那么就一定会产生碰撞(鸽笼原理)所以一般来说一个好的散列算法可以在内容小于尝试空间时候尽量避免碰撞(尽量将结果随机化)

    生日问题

一个班级所有人的生日都不相同的几率是多少?例如一个班级有22个人,其所有人的生日都不相同的几率是多少?

很多人都认为这个记录很小,潜意识之中会认为是22/365≈6%, 但是实际上其几乎为50%

怎么计算?

看成打靶盲射问题,维基百科之中的生日攻击写的非常清楚,其是逐渐减小的概率的阶乘,从方程公式1中可看出。当n=30时候,其概率大于70%

哈希函数的取值空间是所有可能的组合。例如有10位,每一位可以是所有数字加上字母(10+26+26)=62,那么就是62^10 种组合。其不仅与位数有关。换句话说,哪怕只有一位,但是这一位上面可以有62^10 种不同的标识符,那么和之前的10位每一位有62种标识符的是一样的

4.SHA

直接看维基百科即可。SHA家族目前有SHA-0(发布没多久就被撤回),SHA-1(只在压缩函数的消息转换部分差了一个比特的循环位移,也被证明有缺陷且已经有成功的碰撞攻击),SHA-2(当前认为比较安全),SHA-3等等。 具体算法网上全有,主要是使用位运算加上循环,此处不再赘述