Raft 是一个用于管理复制日志（实现分布式共识）的算法。它和 Paxos 一样，都是为了解决分布式系统中多个节点如何就一个值（或一系列值）达成一致的问题。Raft 是 Paxos 的现代简化版本，核心目标相同，但设计理念和实现方式有很大不同，旨在比 Paxos 更易于理解和实现。
Raft 由 Diego Ongaro 和 John Ousterhout 在 2014 年的论文《In Search of an Understandable Consensus Algorithm》中提出。其核心目标是设计一个易于理解的共识算法，以便于教学和工程实现。
Raft 通过强领导制来简化管理。它将共识问题分解为三个相对独立的子问题：
Redis（Remote Dictionary Server）是一个开源的内存数据结构键值存储系统，可以用作数据库、缓存和消息中间件。它支持多种数据结构，如： 字符串、哈希、列表、集合和有序集合等。
Redis 提供了丰富的操作命令，并将数据存储在内存中，因此具有极高的读写性能。同时，它也支持持久化，可以将数据保存到磁盘上，确保数据的安全。
Redis 还支持以下高可用架构，能够满足不同场景下的需求：
| 数据类型 | 特点 | 实现原理 | 典型应用 |
|---|---|---|---|
| String（字符串） | 1. 二进制安全，可存文本/数字/二进制 2. 最大512MB 3. 支持原子操作 |
1. SDS（Simple Dynamic String）实现 2. 预分配空间，减少内存分配 3. 惰性删除空间 |
1. 缓存（session/页面） 2. 计数器（INCR/DECR） 3. 分布式锁（SET NX） |
| Hash（哈希） | 1. 字段-值对集合 2. 适合存储对象 3. 每个Hash可存2³²-1对 |
1. 哈希表 + 压缩列表 2. 小Hash用ziplist节省内存 3. 大Hash用hashtable |
1. 用户信息存储 2. 商品属性 3. 配置项管理 |
| List（列表） | 1. 有序字符串集合 2. 按照插入顺序排序 3. 可重复元素 4. 两端操作O(1) |
1. 快速链表（quicklist） 2. 双向链表节点 + ziplist 3. 压缩中间节点节省内存 |
1. 消息队列 2. 最新文章列表 3. 任务队列 |
| Set（集合） | 1. 无序唯一元素集合 2. 支持集合运算 3. 最大2³²-1元素 |
1. 哈希表实现（值NULL） 2. 小集合用intset（整数集合） 3. 自动升级结构 |
1. 标签系统 2. 共同好友 3. 独立IP统计 |
| Sorted Set（有序集合） | 1. 元素唯一，分数可重复 2. 按分数排序 3. 范围查询高效 |
1. 哈希表 + 跳表（skiplist） 2. 小集合用ziplist 3. O(logN)查找插入 |
1. 排行榜 2. 带权重队列 3. 范围查找 |
| Bitmaps（位图） | 1. 本质上就是String 2. 按位操作 3. 极其节省空间 |
1. 基于String的位操作 2. SETBIT/GETBIT命令 3. 自动扩展 |
1. 用户签到 2. 活跃用户统计 3. 布隆过滤器 |
| HyperLogLog | 1. 基数估算 2. 误差率0.81% 3. 固定12KB内存 |
1. 概率算法 2. 使用16384个6bit寄存器 3. 分桶调和平均数 |
1. UV统计 2. 独立搜索词统计 3. 大规模去重 |
| Geospatial（地理位置） | 1. 存储经纬度 2. 距离计算 3. 范围查询 |
1. 基于Sorted Set实现 2. GeoHash编码 3. 将二维坐标映射为一维 |
1. 附近的人 2. 地理位置搜索 3. 距离计算 |
| Stream（流） | 1. Redis 5.0+ 2. 消息持久化 3. 消费者组 |
1. Rax树（基数树） 2. 链表存储消息 3. 可持久化 |
1. 消息队列 2. 事件溯源 3. 日志收集 |
Apache Kafka 是一个分布式的、高吞吐量、高可扩展性的流处理平台。它主要用于构建实时的数据管道和流式应用程序。它可以被看作是一种分布式的、基于发布/订阅模式的消息队列。
它的核心能力可以概括为以下三项：
Producer：生产者
Consumer：消费者
Broker：代理/服务器
Cluster：集群
Controller：控制器
ZooKeeper
这些理论是理解和设计分布式系统的根本。
CAP定理是分布式系统领域最著名的理论，它指出对于一个分布式系统来说，以下三者不可兼得，最多只能同时满足两项：
可以对排序的字段添加相应顺序的索引，来避免 using filesort。
常发生在执行包含排序（GROUP BY, ORDER BY）、去重（DISTINCT）或联合（UNION）等操作的查询时。当 MySQL
在执行查询时，无法直接通过索引获得所需的有序结果，它就需要创建一个内部临时表来存储中间结果，以便进行后续的操作（如排序、分组、去重等）。
Innodb为了解决可重复读隔离级别下的幻读问题，引入了Next-Key Lock，它包括了记录锁（Record Lock）和间隙锁（Gap Lock）。
共同的间隙锁包含：
本文收集了Linux相关的性能指标和工具。大部分资料来源于极客时间课程《Linux性能优化实战》，工具使用资料大部分来源于：linux-command。
假设要开发一款基于地理位置的交友软件，其中最核心的功能为用户匹配其邻近的用户。为了实现这个功能，可以把每个用户的经纬度记录下来，之后，可以使用半正矢公式计算两个用户经纬度之间的距离。
可以把用户经纬度数据都存到数据库里，然后用SQL查询附近的用户：
select * from user where latitude between LAT-D and LAT+D and longitude between LNG-D and LNG+D;如果有网络分区partition (P)，系统就必须在可用性availability和一致性consistency (A and C)之间取得平衡; 否则else (E) 当系统运行在无分区情况下,系统需要在 延迟latency (L) 和 consistency (C)之间取得平衡。
PACELC定理是CAP定理的扩展。
MongoDB（默认配置）下是PA/EC系统，mongo读写都在主节点上，它只需在主节点上写入成功就返回（不像raft需要多数复制成功），当主节点和备节点分区时，可能会丢失数据，所以说PA，在无分区的情况下，由于读写都在主节点，肯定能读到最新写入的数据，所以是EC。另外Mongo可以配置为写入大多数节点读主节点，这样就是PC/EC系统了。
生产环境的JVM进程经常被运维报告有OOM的情况，运维的描述是，内存一直在缓慢增长，1-2天就会出现OOM的情况。因为已经严重影响到客户的使用，所以采取由运维定时监控，与客户交流，开发负责排查问题的策略。
由于开发是没权限进入生产环境的，要高效率解决问题，必须能在测试环境复现。查看生产环境的日志，确认容器出发OOM的接口，然后使用Jmeter在测试环境压测该接口，发生OOM的情况，问题能够复现。
在测试环境建一个和生产环境规格一样的容器，使用Jmeter压测，确认问题能复现。