哈希

把Mysql结果集缓存到Redis的字符串或哈希结构中以后，我们面临一个新的问题，即如何为这些字符串或哈希命名，也就是如何确定它们的键。因为这些数据结构所对应的行都属于某个结果集，假如可以找到一种唯一标识结果集的方法，那么只需为这些数据结构分配一个唯一的序号，然后把结果集标识符与该序号结合起来，就能唯一标识一个数据结构了。于是，为字符串和哈希命名的问题就转化为确定结果集标识符的问题。 经过调研，发现一种较为通用的确定结果集标识符的方法。正如我们所知道的，缓存在Redis中的结果集数据都是利用select等sql语句从Mysql中获取的。同样的查询语句会生成同样的结果集（这里暂时不讨论结果集中每条记录的顺序问题），这一性质刚好可以用来确定结果集的唯一标识符。当然，简单地把整个sql语句作为结果集标识符是不可取的，一个显而易见的理由是，未经处理的sql查询语句均包含若干空格，而Redis的键是不允许存在空格的。这时，我们需要一个可以把sql语句转换为唯一标识符的函数。通常，这一功能由散列函数完成，包括MD5，SHA系列等加密散列函数在内的很多算法均可达到这一目的。 确定结果集标识符之后，从Redis读数据或向Redis写数据的思路就很清晰了。对于一个sql语句格式的数据请求，首先计算该语句的MD5并据此得到结果集标识符，然后利用该标识符在Redis中查找该结果集。注意

Redis真集群安装 命令文档: http://redisdoc.com/index.html 下载： https://code.google.com/archive/p/redis/downloads 官方地址： https://redis.io 安装 请用 root 用户。 安装Ruby Centos yum -y install ruby ruby-devel rubygems rpm-build gpg2 --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 curl -L get.rvm.io | bash -s stable source /usr/local/rvm/scripts/rvm rvm list known rvm install 2.4.1 gem install redis yum install -y rubygems 安装Redis 编辑配置，然后启动。 src/redis-server cluster/7000.conf src/redis-server cluster/7001.conf src/redis-server cluster/7002.conf src/redis-server cluster/7003.conf src/redis-server cluster/7004.conf

MySQL主要有两种结构： Hash索引 B+ Tree索引(InnoDB引擎) B+ Tree索引和Hash索引区别？ 哈希索引适合等值查询，但是无法进行范围查询 哈希索引没办法利用索引完成排序 哈希索引不支持多列联合索引的最左匹配规则 如果有大量重复键值的情况下，哈希索引的效率会很低，因为存在哈希碰撞问题 覆盖索引（covering index）指一个查询语句的执行只用从索引中就能够取得，不必从数据表中读取。也可以称之为实现了索引覆盖。 当一条查询语句符合覆盖索引条件时，MySQL只需要通过索引就可以返回查询所需要的数据，这样避免了查到索引后再返回表操作，减少I/O提高效率。 索引失效： 没有遵循最左匹配原则（组合索引的第一个字段必须出现在查询语句中） or、!=、not in、is [not] null like '%……' 隐式转换 索引字段应用内部函数或运算 三范式： 原子性：数据列不可再分 每一行数据具有唯一性，并消除数据之间的"部分依赖"（联合主键） 独立性、消除传递依赖 数据库优化： 优化sql 创建索引 分表：水平分表（数据比较多）、垂直分表（字段值比较少使用） 读写分离 缓存：使用redis作为中央缓存，在持久层（dao）和数据库之间添加一个缓存层 慢查询定位： set GLOBAL slow_query_log = ON; set GLOBAL slow

https://wenku.baidu.com/view/1da449b6581b6bd97e19ea0b.html 来源： https://blog.csdn.net/wr1997/article/details/102759867

本篇是iOS逆向开发的递进篇-关于哈希算法、数字签名及对称加密等，下面我们着重讲解此内容，希望对大家有所帮助！！！ 一、哈希 1.1 基本内容 哈希表也称为散列表（Hash table），是根据关键码值（key，value），直接进行访问的数据结构。通过把关键码映射到表中的一个位置来进行访问记录，用来加快查找速度。映射函数也称之为散列函数，存放记录数组称为散列表。 假设没有内存限制，直接可以将键作为数组的索引，那么所有的查找仅仅需要一次即可完成。但是这种理想的情况也不会一直出现，因为牵扯到内存问题。从另一个角度来说，如果没有时间来限制，我们也可以使用无序数组并进行顺序查找，这样也会使用较少的内存。 使用哈希查找算法分为两个步骤： 使用Hash函数将被要查找的键转化为数组中的一个索引。理想情况下，不同的键都可以转为不同的索引值。但这仅仅是理想情况下，在实际的开发运算中，我们还是要处理两个或者多个键值散列到同个索引值的情况。 要处理碰撞冲突的过程。 目前本人博客关于讲述哈希思想查找元素的博客有： https://www.cnblogs.com/guohai-stronger/p/11506990.html ，还会持续更新此类算法思想有关的题目。 1.2 哈希函数的两种解决碰撞的方式 1.2.1 拉链法（separate chaining） 拉链法简单说就是链表+数组

哈希是密码学的基础，理解哈希是理解数字签名和加密通信等技术的必要前提。 一. 基本含义： 哈希，英文是 hash ，本来意思是”切碎并搅拌“，有一种食物就叫 Hash ，就是把食材切碎并搅拌一下做成的。哈希函数的运算结果就是哈希值，通常简称为哈希。哈希函数有时候也翻译做散列函数。 根据维基百科的定义，哈希函数要做的事情是 给一个任意大小的数据 生成出一个 固定长度 的数据，作为它的映射。所谓映射就是一一对应。一个可靠的哈希算法要满足三点。 第一是安全，给定数据 M 容易算出哈希值 X ，而给定 X 不能算出 M ，或者说哈希算法应该是一个单向算法。 第二是独一无二，两个不同的数据，要拥有不相同的哈希。 第三是长度固定，给定一种哈希算法，不管输入是多大的数据，输出长度都是固定的。 但是仔细想一下，如果哈希的长度是固定的，也就是取值范围是有限的，而输入数据的取值范围是无限的，所以总会找到两个不同的输入拥有相同的哈希。所以，哈希函数的安全性肯定是个相对概念。如果出现了两个不同输入有相同输出的情况，就叫碰撞，collision 。不同的哈希算法，哈希位数越多，也就基本意味着安全级别越高，或者说它的”抗碰撞性“就越好。 二. 哈希算法的主要作用： 再来说说哈希函数的主要作用。哈希的独一无二性，保证了如果数据在存储或者传输过程中有丝毫损坏，那么它的哈希就会变

这篇文章主要介绍了详解webpack中的hash、chunkhash、contenthash区别，详细的介绍了hash、chunkhash、contenthash的用法和区别 hash、chunkhash、contenthash hash一般是结合CDN缓存来使用，通过webpack构建之后，生成对应文件名自动带上对应的MD5值。如果文件内容改变的话，那么对应文件哈希值也会改变，对应的HTML引用的URL地址也会改变，触发CDN服务器从源服务器上拉取对应数据，进而更新本地缓存。但是在实际使用的时候，这几种hash计算还是有一定区别。 hash hash是跟整个项目的构建相关，只要项目里有文件更改，整个项目构建的hash值都会更改，并且全部文件都共用相同的hash值 构建生成的文件hash值都是一样的，所以hash计算是跟整个项目的构建相关，同一次构建过程中生成的哈希都是一样的 chunkhash 采用hash计算的话，每一次构建后生成的哈希值都不一样，即使文件内容压根没有改变。这样子是没办法实现缓存效果，我们需要换另一种哈希值计算方式，即chunkhash。 chunkhash和hash不一样，它根据不同的入口文件(Entry)进行依赖文件解析、构建对应的chunk，生成对应的哈希值。我们在生产环境里把一些公共库和程序入口文件区分开，单独打包构建

Redis集群是可以在多个Redis节点之间进行数据共享的架构。Redis集群通过分区容错（Partiton）来提高可用性（Availability），即使集群中有一部分节点失效或者无法进行通信，集群也可以继续处理请求。 Redis集群模式数据共享 Redis集群有以下特点： 将数据切分到多个Redis节点 当集群中部分节点失效或者无法进行通信时，整个集群仍然可以处理请求。 Redis将数据分片，每个Redis集群中包含16384个哈希槽（hash slot），Redis中存储的每个key都属于这些哈希槽中的一个。 Redis集群中的每个Redis节点负责处理一部分哈希槽，通过这种将哈希槽分布到不同Redis节点的做法使得用户可以很容易的向集群中添加或者删除Redis节点。如向Redis集群中加入节点D，只需将节点A、B、C中的部分哈希槽移动到节点D即可。 Redis集群中的一致性问题 在谈Redis集群一致性问题前，先了解CAP定理。 CAP定理指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）三者不可兼得，只能同时满足其中的两个 。 Redis集群作为一个分布式系统，也存在相应的问题，Redis对可用性和分区容错性有较好的支持。因此Redis集群模式下数据一致性存在一定的问题

一个很神的根号算法 先鸽着 来源： https://www.cnblogs.com/FlySakura/p/11729859.html

pass the hash原理： 在Windows系统中，通常会使用NTLM身份认证，NTLM认证不使用明文口令，而是使用口令加密后的hash值，hash值由系统API生成(例如LsaLogonUser) ，其中hash(哈希)分为LM hash和NT hash，如果密码长度大于15，那么无法生成LM hash。 从Windows Vista和Windows Server 2008开始，微软默认禁用LM hash，如果攻击者获得了hash，就能够在身份验证的时候模拟该用户(即跳过调用API生成hash的过程) 这类攻击适用于： 域/工作组环境 演示： 靶机：win08 r2 攻击：win08 r2 1.靶机中进行读取NTLM HASH： 2.攻击机执行： mimikatz.exe "privilege::debug" "sekurlsa::pth /user:administrator /domain:top.pentest.top /ntlm:044dfa0c35b979ed369f7335b5ea20e0" 会反弹一个cmd窗口回来 发现hash成功传递！！！ 总结： 在内网渗透中，当我们能够读取ntlm，但是发现抓取不到明文的时候，可以通过hash传递的方式进行横向移动。 对于哈希传递不只是通过mimikatz，还可以通过wce，impacket工具包进行攻击。 来源：