redis主从同步
Redis主从同步全量同步主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点，流程：
这里有一个问题，master如何得知salve是第一次来连接呢？？
有几个概念，可以作为判断依据：
Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。
因此slave做数据同步，必须向master声明自己的replication id 和offset，master才可以判断到底需要同步哪些数据。
因为slave原本也是一个master，有自己的replid和offset，当第一次变成slave，与master建立连接时，发送的replid和offset是自己的replid和offset。
ma ...
ElasticSearch性能优化
硬件配置优化
升级硬件设备配置一直都是提高服务能力最快速有效的手段，在系统层面能够影响应用性能的一般包括三个因素：CPU、内存和 IO，可以从这三方面进行 ES 的性能优化工作。
CPU 配置一般说来，CPU 繁忙的原因有以下几个：
线程中有无限空循环、无阻塞、正则匹配或者单纯的计算；
发生了频繁的 GC；
多线程的上下文切换；
大多数 Elasticsearch 部署往往对 CPU 要求不高。因此，相对其它资源，具体配置多少个（CPU）不是那么关键。你应该选择具有多个内核的现代处理器，常见的集群使用 2 到 8 个核的机器。如果你要在更快的 CPUs 和更多的核数之间选择，选择更多的核数更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。
内存配置如果有一种资源是最先被耗尽的，它可能是内存。排序和聚合都很耗内存，所以有足够的堆空间来应付它们是很重要的。即使堆空间是比较小的时候，也能为操作系统文件缓存提供额外的内存。因为 Lucene 使用的许多数据结构是基于磁盘的格式，Elasticsearch 利用操作系统缓存能产生很大效果。
64 GB 内存的机器是非常理想的，但是 ...
ES索引文档流程详解
文档索引步骤顺序单个文档新建单个文档所需要的步骤顺序：
客户端向 Node 1 发送新建、索引或者删除请求。
节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的主分片目前被分配在 Node 3 上。
Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调节点向客户端报告成功。
多个文档使用 bulk 修改多个文档步骤顺序：
客户端向 Node 1 发送 bulk 请求。
Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机。
主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。
文档索引过程详解整体的索引流程
先看下整体的索引流程
协调节点默认使用文档ID参与计算（也支持通过routing） ...
MySQL索引失效情况
MySQL索引失效 简单介绍下几种MySQL索引失效的常见情况。
1.数据准备 首先准备一张数据表user_info并建立索引
`CREATE TABLE `user_info` (
`id` int(8) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
`number` varchar(12) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '编号',
`username` varchar(16) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '用户名',
`age` int(11) DEFAULT NULL COMMENT '年龄',
`birthday` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '生日',
PRIMARY KEY (`id` ...
Redis 性能优化方案
Redis 是基于单线程模型实现的，也就是 Redis 是使用一个线程来处理所有的客户端请求的，尽管 Redis 使用了非阻塞式 IO，并且对各种命令都做了优化（大部分命令操作时间复杂度都是 O(1)），但由于 Redis 是单线程执行的特点，因此它对性能的要求更加苛刻，本文我们将通过一些优化手段，让 Redis 更加高效的运行。
本文我们将使用以下手段，来提升 Redis 的运行速度：
缩短键值对的存储长度；
使用 lazy free（延迟删除）特性；
设置键值的过期时间；
禁用耗时长的查询命令；
使用 slowlog 优化耗时命令；
使用 Pipeline 批量操作数据；
避免大量数据同时失效；
客户端使用优化；
限制 Redis 内存大小；
使用物理机而非虚拟机安装 Redis 服务；
检查数据持久化策略；
使用分布式架构来增加读写速度。
缩短键值对的存储长度键值对的长度是和性能成反比的，比如我们来做一组写入数据的性能测试，执行结果如下：
数据量
key 大小
value 大小
string:set 平均耗时
hash:hset 平均耗时
100w
20byte
...
布隆过滤器安装与使用及原理
开启布隆过滤器在 Redis 中不能直接使用布隆过滤器，但我们可以通过 Redis 4.0 版本之后提供的 modules（扩展模块）的方式引入，本文提供两种方式的开启方式。
方式一：编译方式1. 下载并安装布隆过滤器
git clone https://github.com/RedisLabsModules/redisbloom.git
cd redisbloom
make # 编译redisbloom
编译正常执行完，会在根目录生成一个 redisbloom.so 文件。
2. 启动 Redis 服务器
> ./src/redis-server redis.conf --loadmodule ./src/modules/RedisBloom-master/redisbloom.so
其中 --loadmodule 为加载扩展模块的意思，后面跟的是 redisbloom.so 文件的目录。
方式二：Docker 方式docker pull redislabs/rebloom # 拉取镜像
docker run -p6379:6379 redislabs/ ...
普通索引和唯一索引，应该怎么选择？
在不同的业务场景下，应该选择普通索引，还是唯一索引？
假设你在维护一个市民系统，每个人都有一个唯一的身份证号，而且业务代码已经保证了不会写入两个重复的身份证号。如果市民系统需要按照身份证号查姓名，就会执行类似这样的 SQL 语句：
select name from CUser where id_card = 'xxxxxxxyyyyyyzzzzz';
所以，你一定会考虑在 id_card 字段上建索引。
由于身份证号字段比较大，我不建议你把身份证号当做主键，那么现在你有两个选择，要么给 id_card 字段创建唯一索引，要么创建一个普通索引。如果业务代码已经保证了不会写入重复的身份证号，那么这两个选择逻辑上都是正确的。
现在我要问你的是，从性能的角度考虑，你选择唯一索引还是普通索引呢？选择的依据是什么呢？
简单起见，我们还是用第 4 篇文章[深入浅出索引（上）]中的例子来说明，假设字段 k 上的值都不重复。
图 1 InnoDB 的索引组织结构
接下来，我们就从这两种索引对查询语句和更新语句的性能影响来进行分析。
查询过程假设，执行查询的语句是 select id ...
MySQL字符串字段索引如何设计
现在，几乎所有的系统都支持邮箱登录，如何在邮箱这样的字段上建立合理的索引，是我们今天要讨论的问题。
假设，你现在维护一个支持邮箱登录的系统，用户表是这么定义的：
mysql> create table SUser(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb;
由于要使用邮箱登录，所以业务代码中一定会出现类似于这样的语句：
mysql> select f1, f2 from SUser where email='xxx';
从第 4 和第 5 篇讲解索引的文章中，我们可以知道，如果 email 这个字段上没有索引，那么这个语句就只能做全表扫描。
同时，MySQL 是支持前缀索引的，也就是说，你可以定义字符串的一部分作为索引。默认地，如果你创建索引的语句不指定前缀长度，那么索引就会包含整个字符串。
比如，这两个在 email 字段上创建索引的语句：
mysql> alter table SUser add index index1(email);
或 ...
礼盒的最大甜蜜度
题目介绍 题目链接：2517. 礼盒的最大甜蜜度 - 力扣（Leetcode）
给你一个正整数数组 price ，其中 price[i] 表示第 i 类糖果的价格，另给你一个正整数 k 。
商店组合 k 类 不同 糖果打包成礼盒出售。礼盒的 甜蜜度 是礼盒中任意两种糖果 价格 绝对差的最小值。
返回礼盒的 最大 甜蜜度。
示例 1：
输入：price = [13,5,1,8,21,2], k = 3
输出：8
解释：选出价格分别为 [13,5,21] 的三类糖果。
礼盒的甜蜜度为 min(|13 - 5|, |13 - 21|, |5 - 21|) = min(8, 8, 16) = 8 。
可以证明能够取得的最大甜蜜度就是 8 。
示例 2：
输入：price = [1,3,1], k = 2
输出：2
解释：选出价格分别为 [1,3] 的两类糖果。
礼盒的甜蜜度为 min(|1 - 3|) = min(2) = 2 。
可以证明能够取得的最大甜蜜度就是 2 。
示例 3：
输入：price = [7,7,7,7], k = 2
输出：0
解释：从现有的糖果中任选两类糖果 ...
CMS和G1
CMSCMS 的全称是 Mostly Concurrent Mark and Sweep Garbage Collector（主要并发标记清除垃圾收集器），它在年轻代使用复制算法，而对老年代使用标记-清除算法。你可以看到，在老年代阶段，比起 Mark-Sweep，它多了一个并发字样。
CMS 的设计目标，是避免在老年代 GC 时出现长时间的卡顿（但它并不是一个老年代回收器）。如果你不希望有长时间的停顿，同时你的 CPU 资源也比较丰富，使用 CMS 是比较合适的。
CMS 使用的是 Sweep 而不是 Compact，所以它的主要问题是碎片化。随着 JVM 的长时间运行，碎片化会越来越严重，只有通过 Full GC 才能完成整理。
为什么 CMS 能够获得更小的停顿时间呢？主要是因为它把最耗时的一些操作，做成了和应用线程并行。接下来我们简要看一下这个过程。
CMS 回收过程初始标记（Initial Mark）初始标记阶段，只标记直接关联 GC root 的对象，不用向下追溯。因为最耗时的就在 tracing 阶段，这样就极大地缩短了初始标记时间。
这个过程是 STW 的，但由于只 ...