哈希

字典 ​ 字典(dict)是python中唯一一个映射类型,在python中key是唯一的,在保存的时候,根据key计算出一个内存地址,然后将key-value保存在这个地址中,这种算法被称为hash算法.所以,在dict中存储的键值对中的key必须是可哈希的.(可以改变的都是不可哈希的,那么可哈希的就意味着不可变.)这是为了能准确地计算内存地址而规定的.还有,dict保存的数据不是按照我们添加进去的顺序保存的,是按照hash表的顺序保存的,而hash表不是连续的,所以不能进行切片工作,只能通过key来获取dict中的数据. 已知的可哈希(不可变)的数据类型:int,bool,str,tuple;不可哈希(可变)的数据类型:list,dict,set 顺便回忆:可迭代的数据类型:除了int和bool,其他都可迭代 增 ​ 字典名[键] = 值 无则添加,有则修改 ​ 字典名.setdefault(键,值): 无则添加,有则不添加 删 ​ 字典名.pop(键) 通过键进行删除.原地删除,返回的也是被删除的值 ​ 字典名.popitem() 随机删除 python3.6默认删除最后一个,返回值是被删除的键值对 ​ 字典名.clear() 清空 ​ del 字典名 删除整个容器 ​ del 字典名[键] 通过键进行删除 ​ 字典中没有remove 改 ​ 字典名[键] = 值 无则添加

hashcat官网：https://hashcat.net/hashcat/ GitHub项目：https://github.com/hashcat/hashcat 基本语法：hashcat.exe [选项] <单个哈希/哈希列表> <密码字典> 常用选项： -m, --hash-type 哈希类型，如: -m 100 -a, --attack-mode 攻击模式，如: -a 3 哈希类型（哈希模式）： 900 MD4 0 MD5 100 SHA1 10 md5($pass.$salt) 20 md5($salt.$pass) 3710 md5($salt.md5($pass)) 2600 md5(md5($pass)) 5500 NetNTLMv1 5600 NetNTLMv2 16500 JWT (JSON Web Token) 11 Joomla < 2.5.18 400 Joomla >= 2.5.18 (MD5) 400 WordPress (MD5) 7900 Drupal7 131 MSSQL (2000) 132 MSSQL (2005) 1731 MSSQL (2012, 2014) 300 MySQL4.1/MySQL5 15000 FileZilla Server >= 0.9.55 1000 NTLM 攻击模式： 0 Straight（密码字典） 1

一．为什么要用集群 redis3.0 集群采用 P2P 模式，完全去中心化，将 redis 所有的 key 分成了 16384 个槽位，每个 redis 实例负责一部分 slot ，集群中的所有信息通过节点数据交换而更新。 redis 实例集群主要思想是 将 redis 数据的 key 进行散列，通过 hash 函数特定的 key 会映射到指定的 redis 节点上 二． 数据分布理论 分布式数据库首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。 常见的分区规则有哈希分区和顺序分区。 Redis Cluster 采用哈希分区规则，因此接下来会讨论哈希分区规则。 (1) 节点取余分区 (2) 一致性哈希分区 (3) 虚拟槽分区 (redis-cluster 采用的方式) 顺序分布 那么同样的分 4个节点就是hash(key)%4 节点取余的优点是简单，客户端分片直接是哈希 +取余 一致性哈希 客户端进行分片，哈希 +顺时针取余 三． redis 虚拟槽分区 Redis Cluster 采用虚拟槽分区 虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（ slot ）。 Redis Cluster 槽的范围是 0 ～ 16383 。

现象:用户读信时,根据路径的哈希结果,访问四台服务器中一台请求文件,这四台缓存机器已经下线,访问不到再去后端存储访问浪费了时间 前因:每一封信都是一个文件,存储在公司内部的分布式文件系统s3上.因为读取速度太慢和经常的网络访问失败,后来在s3系统之上新增了nginx缓存代理,imap pop web各端都能使用这几台缓存.又增加了阿里云oss存储,与s3存储并行. 1. 访问文件的时候,会根据内部的索引服务返回的location进行判断,结果是4,5,6,分别代表只存s3,只存oss,s3和oss双读.代码中对location进行判断,进行读取访问文件.当存在双读的时候,要根据配置优先读取oss或者优先读取s3,读取不到时再去读取另外的存储 2. 在需要读取s3时,在这之上要先访问缓存代理.根据指定的哈希规则,对path部分取哈希值,如果在以下四个范围内就访问指定的IP '0~25'=>'http://xxx.xxx.88', '25~50'=>'http://xxx.xxx.89', '50~75'=>'http://xxx.xxx.90', '75~100'=>'http://xxx.xxx.91' 哈希算法如下: function BKDRHash($str) { $hash = 0; $seed = 1313; for ($i=0;$i<strlen($str);$i++)

哈希 哈希是一个系列的加密算法， 各个不同的哈希算法虽然加密强度不同， 但是有以下 几个共同点： ①不管输入数据的数据量有多大，输入同一个哈希算法，得到的加密结果长度固定。 ②哈希算法确定， 输入数据确定， 输出数据能够保证不变 ③哈希算法确定， 输入数据有变化， 输出数据一定有变化， 而且通常变化很大 ④哈希算法不可逆 Git 底层采用的是 SHA-1 算法 哈希算法可以被用来验证文件。 Git 就是靠这种机制来从根本上保证数据完整性的。 Git 保存版本的机制 集中式版本控制工具的文件管理机制 以文件变更列表的方式存储信息。这类系统将它们保存的信息看作是一组基本 文件和每个文件随时间逐步累积的差异 。 Git 的文件管理机制 Git 把数据看作是小型文件系统的一组快照。 每次提交更新时 Git 都会对当前 的全部文件制作一个快照并保存这个快照的索引。 为了高效， 如果文件没有修改， Git 不再重新存储该文件， 而是只保留一个链接指向之前存储的文件。 所以 Git 的 工作方式可以称之为快照流。 Git 文件管理机制细节 Git的提交对象 我们 add 的每一个文件都会被加密后得到一个哈希值，然后放到树中，树中有提交的每个文件的哈希值，同时这个树也会有一个哈希值，提交后会把这个树的哈希值、提交的数量、提交者、作者等这一些信息加密后又得到一个哈希值，这也就是我们的一个版本信息。

默克尔树 以太坊的主要数据对象之前，我想先向各位简要介绍一下默尔克树到底是什么，以使得它得以发挥作用的属性特征 假设由定制的默克尔-帕特里夏树维护世界状态和交易。 在默克尔树中， 由叶子节点保存区块数据的哈希，而由非叶子节点保存其子节点的哈希。 -默克尔树示意图（包括节点以及他们之间的关系） 默克尔树所 指向数据的任何改动都会引起节点哈希的变化。 由于每一个父节点中所保存的哈希值都取决于子节点所包含的数据，所以子节点中数据的变更都会引起父节点哈希的变化。并且这样的影响是连锁反应，从叶子节点直达根节点的。因此对叶子节点所指向数据的改动会引起根节点所保存哈希的变化。由上述结构特征，我们可以引申出两条重要的属性： 在判断两棵默克尔树所指向数据是否完全相同时，我们不需要比较每个叶子节点，而只需比较根节点所保存的哈希。 在判断特定数据是否被树所指向时，我们可以使用 默克尔证明 技术。此处不对该技术作过多介绍，只需知道这是证明数据存在于默克尔树中的一种简单、高效的方法。 第一种属性的重要之处在于，我们能够仅利用根节点的哈希值，就标示某一时刻整棵树所指向的数据。这意味着仅通过保存根节点的哈希值就能标示区块（无需储存区块链中所有的数据），且维护数据的不可篡改。 至此我们理清了默克尔树中根节点哈希的作用，下面来介绍以太坊中的主要对象。 世界状态 世界状态是地址（账户）到账户状态的映射

题目链接： https://www.luogu.org/problemnew/show/P3370 参考了洛谷的博客： https://www.luogu.org/blog/pks-LOVING/zi-fu-chuan-xue-xi-bi-ji-ha-xi-hash-yu-zi-dian-shu-trie 　　　　　　　　　 https://www.luogu.org/blog/yhzq/solution-p3370 对字符串进行进制哈希就是取一个数字base（一般是质数）当做固定的进制，我们将字符串看成这个进制数字，然后将字符串（base进制数）转换成十进制数，这中间一般都会进行取模，防止数据溢出，最终得到的这个值我们就成为这个字符串的哈希值，如果两个字符串的hash值是相同的，我们一般就把这两个字符串看成是相同的字符串。我们的任务就是尽量使不同的字符串哈希之后到的哈希值不同，如果两个不同的字符串的哈希值相同，我们就称它为哈希冲突，当然，我们无法使两个不同的字符串的哈希值一定不同，只能尽量去减小哈希冲突的概率。 为了增加我们的准确率，我们可以对一个字符串进行两次（或者多次）不同的hash，只有所有的哈希值都相同的时候，我们才将两个字符串看成是相等的字符串，虽然这样会增加时间和空间的开销，但是可以明显的提高我们的准确率。 对于mod，我们可以将哈希值定义为undigned long

Python深浅拷贝 拷贝（赋值）、浅拷贝、深拷贝 可变or不可变：d不变值可变，即在原值的基础上修改，则为可变数据类型；值变id也变，即重新申请一个空间放入新值，则为不可变数据类型。 拷贝 如果l2是l1的拷贝对象，则l1内部的任何数据类型的元素变化，则l2内部的元素也会跟着改变，因为可变类型值变id不变。 浅拷贝 如果l2是l1的浅拷贝对象，则l1内的不可变元素发生了改变，l2不变；如果l1内的可变元素发生了改变，则l2会跟着改变。 深拷贝 如果l2是l1的深拷贝对象，则l1内的不可变元素发生了改变，l2不变；如果l1内的可变元素发生了改变，l2也不会变，即l2永远不会因为l1的变化而变化。 哈希表 ​ 散列表（Hash table，也叫哈希表），是根据关键码值(Key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。这个映射函数叫做散列函数，存放记录的数组叫做散列表。 ​ 给定表M，存在函数f(key)，对任意给定的关键字值key，代入函数后若能得到包含该关键字的记录在表中的地址，则称表M为哈希(Hash）表，函数f(key)为哈希(Hash) 函数。 基本概念 若关键字为 k ，则其值存放在 f(k) 的存储位置上。由此，不需比较便可直接取得所查记录。称这个对应关系 f 为散列函数，按这个思想建立的表为散列表。

转载自： https://blog.csdn.net/losetowin/article/details/53743135 适当做了一些修改,最后加了自己的一些理解 1、项目场景 (1) 单个节点的缓存容量达到上限，无法继续单点增加内存，如何解决？ (2) 单个节点 支撑的 QPS (每秒查询率)达到上限， 如何解决 ？ 2、 初步方案 增加 N 个 缓存节点 ，为了保证 缓存数据的均匀 ，一般情况会采用对 key值hash ，然后 取模 的方式，然后根据结果，确认数据落到哪台节点上：如下： hash(key)%N 很好，这个的确解决了上面的问题，实现了 初步的分布式缓存 ， 数据均匀分散 到了各个节点上， 流量请求也均匀的分散 到了各个节点。 (1) 但是如果出现以下情况，会带来什么问题？ 某台服务器 突然宕机 。缓存服务器从 N 变为 N-1 台。 缓存容量 达到 上限 或者 请求处理达到上限 ，需要 增加缓存服务器 ，假定增加1台，则缓存服务器从 N 变为 N+1 上面的情况带来的问题： 增加 或者 删除 缓存服务器的时候，意味着 大部分的缓存都会失效 。这个是 比较致命 的一点，缓存失效，如果 业务为缓存不命中 ，查询DB的话，会导致 一瞬间DB的压力陡增 。可能会 导致整个服务 不可用。 (2) 换种描述方式，我们需要解决怎么样的问题？或者需求是怎样的？ 增删 机器时，

Redis单节点容量问题 一、单节点容量问题 我们在实际场景中，往往遇上一个单节点容量问题。 1.进行 业务拆分 ，数据分类 2.到了 数据 不能拆分的时候，可以进行数据分片 进行哈希取模（影响分布式下的扩展性%3,%4，如果多加一台机器，就会收到影响） 进行逻辑随机（可以放进去，但是拿不出来） 解决方案：两台机器同时存储一个list，然后client直接连2台redis，进行两台一起消费 一致性哈希算法 crc16 crc32 md5 sha1 sha256 没有进行取模，等宽16位，将16位抽象出一个哈希环，计算一致性哈希算法 一致性哈希算法（哈希环）： 1.求出memcached服务器（节点）的哈希值，并将其配置到0～232的圆（continuum）上。 2.采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。 3.从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过232仍然找不到服务器，就会保存到第一台memcached服务器上。 来源：（https://www.cnblogs.com/williamjie/p/9477852.html） 3.优缺点 优点：加节点的确可以分担其他节点压力（而且也不会造成全局洗牌） 缺点：新增节点会造成一小部分数据不能命中 二、twemproxy twemproxy是一种代理分片机制，由twitter开源