哈希

　　 Git 是神Linus Torvalds使用c开发的一个版本控制系统，该系统的开发基于以下目标： 速度 简单的设计 对非线性开发模式的强力支持（允许成千上万个并行开发的分支） 完全分布式 有能力高效管理类似Linux内核一样的超大规模项目（速度和数据量） 　　那么，Git究竟是怎样一个系统呢？若你理解Git的思想和基本工作原理，用起来会知其所以然、游刃有余。尽管操作起来的命令形式与其他版本控制系统非常相似，但Git在保存和对待各种信息的时候与其他版本控制系统有很大差异，理解这些差异将便于高效使用Git。 1. 直接记录快照，而非差异比较 　　 Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git 对待数据的方法。 理念上看，其他大部分系统以文件变更列表的方式存储信息，这类系统（CVS、Subversion、Perforce、Bazaar等）将它们保存的信息看做一组基本文件和每个文件随时间逐步累积的差异。 　　Git 则把数据看作是对小型文件系统的一组快照。 每次提交更新，或在Git中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。如果没有修改文件，Git不再重新存储文件，而只保留一个链接指向之前存储的文件。Git对待数据更像是一个 快照流。 2. 近乎所有操作都是本地执行 　　 在 Git

前言 当提到MySQL数据库的时候，我们的脑海里会想起几个关键字：索引、事务、数据库锁等等，索引是MySQL的灵魂，是平时进行查询时的利器，也是面试中的重中之重。 可能你了解索引的底层是b+树，会加快查询，也会在表中建立索引，但这是远远不够的，这里列举几个索引常见的面试题： 1、索引为什么要用b+树这种数据结构？ 2、聚集索引和非聚集索引的区别？ 3、索引什么时候会失效，最左匹配原则是什么？ 当遇到这些问题的时候，可能会发现自己对索引还是一知半解，今天我们一起学习MySQL的索引。 一、一条查询语句是如何执行的 首先来看在MySQL数据库中，一条查询语句是如何执行的，索引出现在哪个环节，起到了什么作用。 1.1 应用程序发现SQL到服务端 当执行SQL语句时，应用程序会连接到相应的数据库服务器，然后服务器对SQL进行处理。 1.2 查询缓存 接着数据库服务器会先去查询是否有该SQL语句的缓存，key是查询的语句，value是查询的结果。如果你的查询能够直接命中，就会直接从缓存中拿出value来返回客户端。 注：查询不会被解析、不会生成执行计划、不会被执行。 1.3 查询优化处理，生成执行计划 如果没有命中缓存，则开始第三步。 解析SQL：生成解析树，验证关键字如select,where,left join 等）是否正确。 预处理：进一步检查解析树是否合法，如检查数据表和列是否存在

为什么使用引用？ 在perl4中，hash表中的value字段只能是scalar，而不能是list，这对于有些情况是很不方便的，比如有下面的数据： Chicago, USA Frankfurt, Germany Berlin, Germany Washington, USA Helsinki, Finland New York, USA 我们想要按国家将城市分类，每个国家后面对应城市列表，如果用perl4来做，必须将城市列表组合成字符串才行，如果用perl5就可以用引用来做，有了引用，就可以构造复杂的hash结构，就可以用列表作为hash的值了。 如何定义引用 方法一 使用斜线\ 定义变量的时候，在变量名前面加个\，就得到了这个变量的一个引用，比如 # 数组的引用my@array= (1,2,3) ;my$aref=\@array ;#哈希的引用my%hash= ("name"=>"zdd","age"=>30,"gender"=>"male") ;my$href=\%hash ;#标量的引用my$scalar=1 ;my$sref=\$scalar ; 方法二 匿名引用 方法一不是很常用，最常用的还是匿名引用，方法如下 匿名数组引用-用[]定义 $aref= [ 1,"foo",undef,13 ]; 匿名数组的元素仍然可以是匿名数组，所以我们可以用这种方法构造数组的数组

1.哈希函数 密码学中的哈希函数有两个重要的性质，第一是哈希碰撞，哈希碰撞是指给定任意两个输入x、y，并且x≠y使得H(x)=H(y)。关于哈希碰撞有两个很重要的结论，其一哈希碰撞是必然存在的，因为哈希函数的输出空间往往是固定的，但输入空间可以是无限的，所以根据鸽笼原理哈希碰撞是必然存在的。其二是没有办法从理论上证明哈希函数是存在哈希碰撞的。这意味着没有高效的方法去人为制造哈希碰撞，所以哈希碰撞可以用来确定某一个信息是否被篡改过。 第二个性质是哈希函数的计算过程是单向不可逆的，我们没有高效的方法从哈希函数的输出来求的哈希函数的输入。不过这个性质的成立需要满足两个前提条件，一是输入空间足够大，二是输入的分布比较平均。所以我们对一个给定值x取哈希时通常会将x拼接上一个随机数一起取哈希即H(x ll nonce)。 2.签名 在讲签名之前先了解一下比特币账户，比特币中的账户是一对公私钥对，发起一个交易时使用自己的私钥进行签名，发布到网络中，系统中的其它节点可以使用公钥验证签名，这样就可以证明这笔交易确定是由你发起的。这里值得注意的一点是因为公私钥对会使用到哈希函数，所以在实现公私钥对的时候需要一个好的随机源。 来源： https://www.cnblogs.com/yishi-san/p/12512217.html

某厂面试归来，发现自己落伍了！>>> 集群技术是构建高性能网站架构的重要手段，试想在网站承受高并发访问压力的同时，还需要从海量数据中查询出满足条件的数据，并快速响应，我们必然想到的是将数据进行切片，把数据根据某种规则放入多个不同的服务器节点，来降低单节点服务器的压力。 上一篇我们讲到了 Redis 的主从复制技术，当实现了多节点的 master-slave 后，我们也可以把它叫做集群，但我们今天要讲的集群主要是利用切片技术来组建的集群。 集群要实现的目的是要将不同的 key 分散放置到不同的 redis 节点，这里我们需要一个规则或者算法，通常的做法是获取 key 的哈希值，然后根据节点数来求模，但这种做法有其明显的弊端，当我们需要增加或减少一个节点时，会造成大量的 key 无法命中，这种比例是相当高的，所以就有人提出了一致性哈希的概念。 一致性哈希有四个重要特征： 均衡性：也有人把它定义为平衡性，是指哈希的结果能够尽可能分布到所有的节点中去，这样可以有效的利用每个节点上的资源。 单调性：对于单调性有很多翻译让我非常的不解，而我想要的是 当节点数量变化时哈希的结果应尽可能的 保护已分配的内容不会被重新分派到新的节点。 分散性和负载：这两个其实是差不多的意思，就是要求一致性哈希算法对 key 哈希应尽可能的避免重复。 但一致性哈希不是我们今天要介绍的重点，因为 Redis

某厂面试归来，发现自己落伍了！>>> 前言 安全保护几乎对于所有的项目都是一个挑战，对于物联网项目更是如，自普及应用以来物联网业内已经发生过多起安全事故。 作为物联网通信协议事实标准，MQTT 协议保持着较高的安全性，提供了多层次的安全设计： 传输层：MQTT 基于 TCP/IP 协议，可以在传输层上使用 SSL/TLS 进行加密传输： 使用 SSL/TLS 加密通信数据，防止中间人攻击； 使用客户端证书作为设备身份凭证，验证设备合法性。 应用层：使用 MQTT 自身的安全特性进行防护： MQTT 协议支持用户名和密码实现客户端的身份校验； MQTT Broker 实现了 Topic 的读写权限控制（Topic ACL）。 EMQ X MQTT Broker 完整支持 MQTT 协议 各项安全规范，内置的安全功能无需编程开箱即用，可以快速排除项目中的安全隐患。 EMQ X 认证鉴权 系列将围绕各个层次的安全规范，介绍如何通过配置 EMQ X 启用相关功能最终实现相应的安全防护。 本文将围绕 EMQ X 中 MQTT 连接认证相关的核心概念，介绍 EMQ X 支持的认证方式及其适用场景，并从工作机制和配置原则上阐述 EMQ X 认证相关的认证链、认证流程/原理以及相关的配置要点等信息，让你快速掌握 EMQ X 认证配置方式。 认证方式 EMQ X 支持使用内置数据源（文件、内置数据库

目录 LC_28.实现 strStr() * LC_32. 最长有效括号 H* 38. 外观数列 E 重点看：28，32 没意思：38 LC_28.实现 strStr() * 方法一：子串逐一比较 - 线性时间复杂度 最直接的方法 - 沿着主串逐步移动滑动窗口，将窗口内的子串与 needle 字符串比较。（窗口大小=子串长度） 方法二：双指针 - 线性时间复杂度 上一个方法的缺陷是会将 haystack 所有长度为 L 的子串都与 needle 字符串比较，实际上是不需要这么做的。 首先，只有子串的第一个字符跟 needle 字符串第一个字符相同的时候才需要比较 其次，可以一个字符一个字符比较，一旦不匹配了就立刻终止。 方法三： Rabin Karp - 常数复杂度 有一种最坏时间复杂度也为 O(N) 的算法。思路是这样的，先生成窗口内子串的哈希码，然后再跟 needle 字符串的哈希码做比较。 这个思路有一个问题需要解决，如何在常数时间生成子串的哈希码？ 滚动哈希：常数时间生成哈希码 生成一个长度为 L 数组的哈希码，需要 O(L) 时间。 如何在常数时间生成滑动窗口数组的哈希码？利用滑动窗口的特性，每次滑动都有一个元素进，一个出。 由于只会出现小写的英文字母，因此可以将字符串转化成值为 0 到 25 的整数数组： arr[i] = (int)S.charAt(i) - (int

一、负载均衡 1.1.需求 如何实现一个会话粘滞（session sticky）的负载均衡算法？也就是说，在一次会话中的所有请求都路由到同一个服务器上。 1.2.解决方案 通过哈希算法对客户端IP或会话ID计算哈希值，将取得的哈希值与服务器列表的大小进行取模运算，最终得到的值就是应该被路由到的服务器编号。这样，就可以把同一个IP过来的请求都路由到同一个后端服务器上。 二、数据分片 2.1.如何统计“搜索关键词”出现的次数？ ①需求描述 假如我们有1T的日志文件，这里面记录了用户的搜索关键词，我们想要快速统计出每个关键词被搜索的次数，该怎么做呢？ ②问题分析 这个问题有两个难点，第一个是搜索的日子很大，没办法放到一台机器的内存中。第二个是只用一台机器来处理这么巨大的数据，处理时间会很长。 ③解决方案 先对数据进行分片，然后采用多台（比如n台）机器进行处理。具体做法：从搜索记录的日志文件中依次读取每个关键词，并通过哈希函数计算该关键词的哈希值，然后跟机器的台数n取模，最终得到值就是该关键词应该被分到的机器编号，这样相同的关键词一定会被分配到同一台机器上，数据分配完成后，由多台机器并行进行统计，最后合并起来就是最终结果。 实际上，这里的处理过程也是 MapReduce 的基本设计思想。 2.2.如何快速判断图片是否存在图库中？ ①需求描述 假设现在我们的图库中有1亿张图片

为什么需要集群？ 1、性能 Redis本身的QPS已经很高了，但是如果在一些并发量非常高的情况下，性能还是会受到影响。这个时候我们希望有更多的Redis服务来完成工作。 2、扩展 第二个是出于存储的考虑。因为Redis所有的数据都放在内存中，如果数据量大，很容易受到硬件的限制。升级硬件收效和成本比太低，所以我们需要有一种横向扩展的方法。 3、可用性 第三个是可用性和安全的问题。如果只有一个Redis服务，一旦服务宕机，那么所有的客户端都无法访问，会对业务造成很大的影响。另一个，如果硬件发生故障，而单机的数据无法恢复的话，带来的影响也是灾难性的。 可用性、数据安全、性能都可以通过搭建多个Reids服务实现。其中有一个是主节点（master），可以有多个从节点(slave)。主从之间通过数据同步，存储完全相同的数据。如果主节点发生故障，则把某个从节点改成主节点，访问新的主节点。 Redis主从复制（replication） 主从复制配置 例如一主多从,100是主节点，在每个slave节点的redis.conf配置文件增加一行 slaveof 192.168.1.100 6379 //在主从切换的时候，这个配置会被重写成： #GeneratedbyCONFIGREWRITE replicaof 192.168.1.100 6379 或者在启动服务时通过参数指定master节点： .

Greenplum是一个大规模并行处理数据库，它由一个master和多个segment组成，其数据按照设定的分布策略分布于各个segment上。数据表的单个行会被分配到一个或多个segment上，但是有这么多的segment，它到底会被分到哪个或哪些segment上呢？分布策略会告诉我们。 分布策略 在Greenplum 5中，有2种分布策略： 哈希分布 随机分布 在Greenplum 6中，添加了另一个策略： 哈希分布 随机分布 复制分布 数据表的单个行会被分配到一个或多个segment上，但是有这么多的segment，它到底会被分到哪个或哪些segment上呢？分布策略会告诉我们。 哈希分布： 要使用这一策略，需要在创建表使用 “DISTRIBUTED BY（column，[...]）” 子句。 散列算法使分布键将每一行分配给特定segment。相同值的键将始终散列到同一个segment。选择唯一的分布键（例如Primary Key）将确保较均匀的数据分布。哈希分布是表的默认分布策略。 如果创建表时未提供DISTRIBUTED子句，则将PRIMARY KEY（如果表真的有的话）或表的第一个合格列用作分布键。什么类型的列是合格列呢？几何类型或用户自定义数据类型的列不能用作Greenplum分布键列。如果表中没有合格的列，则退化为随机分布策略。 但是