Redis on 小盒子的技术分享

数据库选型终极指南：从数据类型到应用场景，一篇就够了

Fri, 14 Mar 2025 09:19:52 +0000

引言

在当今的数字化时代，数据已成为企业和组织的核心资产。无论是金融交易记录、社交媒体互动、物联网传感器数据，还是企业内部的业务流程信息，都需要通过数据库进行存储、管理和分析。然而，面对市场上数十种主流的数据库技术（如 MySQL、MongoDB、Elasticsearch、HBase、Hive等），如何选择适合自身业务需求的数据库系统，成为许多技术决策者面临的难题。本文将深入探讨数据库的核心分类、技术特性、应用场景以及选择策略，帮助读者构建系统化的选型框架。

数据库的分类

在进行数据库的选择前，你需要至少知道它的分类。

在数据库技术的演进过程中，数据存储模型和应用需求的多样性催生了不同类型的数据库系统。这些系统根据其核心设计理念、数据组织方式以及适用场景的差异，形成了多个分类。

关系型数据库（RDBMS）：结构化数据的基石

关系型数据库的根基是关系代数和集合论，通过二维表（Table）组织数据。每个表由行（记录）和列（字段）构成，通过主键（Primary Key）唯一标识记录，外键（Foreign Key）实现表间的关联。其核心优势在于ACID事务支持，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability），适用于对数据一致性要求极高的场景（如金融交易）

适用场景：

需要强一致性的业务系统（银行核心系统、ERP）。
多表关联查询频繁的OLTP（联机事务处理）场景（电商订单管理）

局限性：

表结构预定义，修改成本高（如新增字段需 ALTER TABLE）。
水平扩展困难，分库分表复杂度高（需处理分布式事务和跨分片查询）。
不适合存储半结构化数据（如JSON文档、嵌套数组）。

代表数据库：MySQL、PostgreSQL、Oracle、SQL Server

NoSQL 数据库：灵活性与扩展性的革命

NoSQL（Not Only SQL）的诞生是为了解决关系型数据库在扩展性、灵活性和高性能场景下的不足。根据数据模型的差异，NoSQL 可进一步细分为四类：

1. 文档型数据库（Document Database）

数据模型：以文档为基本单元，通常采用JSON或BSON格式存储，支持嵌套结构和动态字段

1{
2 "user_id": 101,
3 "name": "张三",
4 "orders": [
5 {"order_id": 2001, "amount": 150.0},
6 {"order_id": 2002, "amount": 300.0}
7 ]
8}

查询能力：支持基于文档属性的查询，部分数据库（如MongoDB）提供类SQL的聚合管道（Aggregation Pipeline）和索引优化。

适用场景：

内容管理系统（CMS）中文章的多版本存储。
用户配置文件的动态字段管理（如社交平台用户的个性化标签）。

局限性：跨文档事务支持较弱（MongoDB 4.0后支持多文档事务，但性能损耗较大）。

代表数据库：MongoDB、Couchbase

2. 键值型数据库（Key-Value Store）

数据模型：最简单的 NoSQL 模型，数据以键值对（Key-Value）形式存储，Value可以是任意二进制数据。

1Key: "user:101:profile"
2Value: "{'name': '李四', 'last_login': '2023-10-01'}"

高性能特性：通过哈希表实现O(1)时间复杂度的读写操作，适合缓存和高并发场景。

适用场景：

会话存储（Session Storage）：快速存取用户登录状态。
分布式缓存（如Redis缓存热门商品信息）。

局限性：缺乏复杂查询能力（仅能通过Key检索），需业务层处理数据关联逻辑。

代表数据库：Redis、Memcached、Amazon DynamoDB

3. 列族数据库（Wide-Column Store）

数据模型：数据按列族（Column Family）组织，每行可动态添加列，适合稀疏矩阵存储。

1Row Key: "device_001"
2Columns: 
3 "metrics:temperature" -> 25.5
4 "metrics:humidity" -> 60%
5 "location:city" -> "北京"

存储优势：基于LSM树（Log-Structured Merge Tree）的存储引擎，优化高吞吐写入（如日志、传感器数据）。

适用场景：

时间序列数据（物联网设备监控）。
海量数据的随机读写（如HBase存储网页爬虫数据）。

局限性：复杂查询需依赖Row Key设计，二级索引支持有限。

代表数据库：Apache HBase、Cassandra、Google Bigtable

4. 图数据库（Graph Database）

数据模型：以图论为基础，通过节点（Node）、边（Edge）、属性（Property）表示实体及其关系。

1Node: User(id=101, name="王五")
2Edge: User101 -[FRIEND]-> User102 (since=2020)

查询优势：专为关系查询优化，可高效遍历多跳关系（如社交网络的六度分隔理论）。

适用场景：

社交网络中的好友推荐。
欺诈检测（识别异常交易环路）。

局限性：非关系场景下性能无明显优势，学习曲线陡峭。

代表数据库：Neo4j、Amazon Neptune

大数据生态数据库：分布式与批量处理的支柱

1. 分布式列式存储（HBase）

技术架构：基于HDFS的分布式存储，通过Region分片实现水平扩展，ZooKeeper协调元数据。

核心能力：

随机实时读写（毫秒级延迟）。
稀疏数据的高效存储（空值不占空间）。

适用场景：实时查询TB级数据（如电信通话记录检索）。

2. 数据仓库（Hive）

技术原理：将结构化数据映射为HDFS文件，通过 HiveQL（类SQL）转换为MapReduce或Tez任务。

核心能力：

离线批量处理（小时级延迟）。
复杂ETL流程（数据清洗、转换）。

适用场景：历史数据报表生成（如零售业月度销售分析）。

3. 实时数仓（ClickHouse、Doris）

技术突破：向量化执行引擎、列式存储、预聚合，实现亚秒级响应。

适用场景：交互式OLAP分析（如广告投放效果实时看板）。

总结

我们做一个整体的对比

随着技术发展，数据库的界限逐渐模糊。例如：

多模型数据库：如PostgreSQL通过扩展支持JSONB（文档模型）和Citus（分布式能力）。
HTAP(Hybrid Transactional/Analytical Processing)数据库：TiDB、Oracle Exadata支持OLTP与OLAP混合负载。
AI驱动数据库：利用机器学习优化查询计划（如Google AlloyDB）。

随着 AI 技术的兴起，向量数据库也是非常热门的一类数据库。数据库的分类也并非绝对的技术壁垒，而是反映了不同场景下的核心矛盾权衡：

结构化 vs 灵活性：关系型牺牲灵活性换取严格约束，文档型反之。
一致性 vs 扩展性：CP系统（如ZooKeeper）优先保障一致性，AP系统（如Cassandra）优先保障可用性。
实时性 vs 吞吐量：HBase优化单点查询延迟，Hive优化批量吞吐量。

理解这些分类背后的哲学，才能避免“技术选型中的锤子效应”（手里只有一把锤子，看所有问题都是钉子），从而在复杂业务场景中构建合理的数据存储架构。

数据类型

在进行数据库的选择前，你要处理的数据类型是你必须要明确的。

结构化、半结构化和非结构化数据在存储、查询和处理方式上存在本质差异，直接影响了技术选型的路径。

在数据管理的实践中，数据类型是决定数据库选型的关键因素之一。结构化、半结构化和非结构化数据在存储、查询和处理方式上存在本质差异，直接影响了技术选型的路径。以下从数据特征、处理需求到典型数据库选择展开系统性分析。

结构化数据：秩序与约束的领域

1. 核心特征

严格模式（Schema）：数据字段预先定义，类型明确（如整数、日期、枚举值）。
二维表结构：数据以行和列的形式组织，遵循第一范式（1NF）到第三范式（3NF）的规范。
强关联性：通过外键建立表间关系，支持JOIN操作实现跨表查询。

示例：

银行账户表：账户ID (主键) | 户主姓名 | 余额 | 开户日期
电商订单表：订单ID | 用户ID (外键) | 商品ID (外键) | 订单金额 | 支付状态

2. 数据库选择

首选：关系型数据库（RDBMS）。它的选型逻辑：

事务完整性：需要ACID保障的场景（如转账操作）。
复杂查询：涉及多表关联、聚合计算（如财务报表生成）。
数据一致性：字段之间存在强约束（如库存数量不能为负值）。

其中代表方案有：

MySQL/PostgreSQL：适用于中小规模OLTP系统。
Oracle：企业级高并发、高可靠性需求（如金融核心系统）。
TiDB：分布式架构下仍需强一致性的场景（如跨境支付平台）。

3. 反模式案例

错误尝试：将用户行为日志（半结构化JSON）存入MySQL。这样做的问题是：

需要为动态字段创建稀疏列，导致存储空间浪费。
频繁ALTER TABLE修改表结构，引发锁表风险。
查询嵌套字段需解析JSON字符串，性能低下。

半结构化数据：灵活性与动态性的平衡

1. 核心特征

松散模式：字段可动态增减，数据类型允许一定灵活性。
层次化结构：数据以树形或网状形式组织（如JSON、XML）。
自描述性：数据本身携带元信息（如字段名称、嵌套关系）。

示例：用户配置文件

 1 {
 2 "user_id": 1001,
 3 "preferences": {
 4 "theme": "dark",
 5 "notifications": {
 6 "email": true,
 7 "sms": false
 8 }
 9 },
10 "last_activity": [
11 {"type": "login", "timestamp": "2023-10-05T08:30:00Z"},
12 {"type": "purchase", "item_id": "SKU123"}
13 ]
14 }

设备传感器元数据：

1 <device id="D001">
2 <location lat="39.9042" lon="116.4074"/>
3 <sensors>
4 <sensor type="temperature" unit="°C"/>
5 <sensor type="humidity" unit="%"/>
6 </sensors>
7 </device>

2. 数据库选择

首选技术：文档型数据库、宽列数据库。它的选型逻辑：

动态模式支持：无需预定义字段，适应业务快速迭代。
嵌套查询效率：直接存储层次化数据，避免关联表拆分。
局部更新能力：修改文档部分字段不影响整体结构。

代表方案：

MongoDB：
适用场景：CMS内容管理、物联网设备元数据存储。
优势：BSON二进制存储、聚合管道、地理位置索引。
限制：事务跨文档操作成本高（需4.0+版本）。
Cassandra：
适用场景：时间序列数据（如日志事件流）。
优势：高写入吞吐、多数据中心复制。
限制：查询必须指定分区键，二级索引效率低。
Elasticsearch：
适用场景：日志分析、全文检索（如电商商品搜索）。
优势：倒排索引、近实时搜索、分词器定制。
限制：写入吞吐受分片数限制，不支持事务。

3. 混合架构实践

典型组合：MySQL + MongoDB + Elasticsearch。数据流示例：

用户注册信息（结构化）存入MySQL。
用户行为轨迹（半结构化JSON）写入MongoDB。
关键字段（如用户ID、行为类型）同步到Elasticsearch供快速检索。

非结构化数据：海量与多元化的挑战

1. 核心特征

无固定模式：数据格式不遵循预定义结构。
大文件倾向：单个数据单元体积大（如视频、图片）。
内容多样性：文本、图像、音频、二进制文件等。

示例：

媒体文件：监控摄像头的1080P视频流（MP4格式）。
办公文档：PDF合同、Word报告。

2. 数据库选择

核心矛盾：非结构化数据的管理重点不是“查询”，而是“存储与访问”。它的选型逻辑：

存储效率：需支持大文件分块存储（如HDFS的128MB块）。
元数据管理：通过附加结构化信息实现快速检索。
访问接口：提供HTTP API或对象存储接口（如S3兼容）。

代表方案：

对象存储：

Amazon S3/阿里云OSS：存储图片、视频等静态资源。
MinIO：自建私有化对象存储方案。

分布式文件系统：

HDFS：用于Hadoop生态的原始文件存储。
Ceph：统一存储池支持块、文件、对象接口。

专用数据库扩展：

MongoDB GridFS：将大文件分块存储为文档。
PostgreSQL大对象（LOB）：通过TOAST机制存储二进制数据。

3. 元数据关联策略

典型架构是：对象存储 + 关系型数据库。分两步：

数据流：

上传视频文件到S3，获得存储路径s3://bucket/video_001.mp4。
在MySQL中创建记录：

1INSERT INTO media_files 
2 (id, s3_path, uploader_id, duration, resolution)
3VALUES 
4 (1001, 's3://bucket/video_001.mp4', 501, 120, '1920x1080');

查询过程：

1-- 查找用户501上传的高清视频
2SELECT s3_path FROM media_files 
3WHERE uploader_id = 501 AND resolution = '1920x1080';

总结

总结一下不同数据类型的特点

总结来说：

结构化数据是商业规则的数字化体现，适合通过关系型数据库实现精准控制。
半结构化数据反映了现实世界的复杂关联，文档型或宽列数据库提供必要的灵活性。
非结构化数据代表信息的原始形态，需通过对象存储与元数据管理实现规模化处理。

说了这么多，虽然对于数据是什么类型有了比较清楚的定义和区分，但是数据到底是结构化的还是非结构化的，其实主要是看 “数据的组织方式”和“处理方式”

这里举个例子，比如 用户评论

如果我们只是想简单的读写用户评论，可以把它用关系型数据库存储，当作一个表中的一个字段:

在评论内容（CommentContent）这个字段中，我们可以存储用户的评论文本。对于包含的表情、图片等多媒体元素，也有一些常见的处理方法。例如，把表情转换为编码存储，而图片可以存储在文件服务器上，并在数据库中保存链接地址。

如果把用户评论当成非结构化数据，那么它的处理方式就会更加复杂。

用户评论的内容通常是文本信息，但其实不容易进行有效的结构化处理。评论的长度、格式、语言等都可能差异很大，甚至某些评论可能包含表情符号或者图片等多媒体元素。这些元素都无法通过预定义的数据模型进行有效地分类和组织，因此我们将其当做非结构化数据来处理。–这里主要是指数据的组织方式。

以下是一些具体的例子：

评论情感分析：通过对用户评论的文本内容分析，我们可以识别出评论者的情绪态度，比如正面的、负面的，或者中性的。这对于公司来说是非常重要的，可以了解产品或者服务在消费者中的口碑和接受程度。
评论分类：我们还可以将评论分到不同的类别。可以根据情绪分为好评、中评、差评。同时，还可以按照评论的内容将其分为产品评价，客服评价等类别。
评论的全文搜索：对于用户评论这种非结构化数据的全文搜索，可以帮助我们即时搜索到关于某一产品或者某一特定主题的所有相关评论。
主题模型：主题模型可以帮助我们从大量的评论中提炼出几个主要的话题，帮助公司了解消费者最关心的问题有哪些。

具体实现架构如下：

用户评论的存储与分析系统需结合多种技术实现高效处理。在存储层设计中，推荐采用混合存储架构以满足非结构化数据的持久化需求。核心存储使用MongoDB文档数据库保存完整的评论内容（如文本、表情编码、图片链接等），其灵活的JSON结构支持动态字段扩展，例如可包含用户设备信息、地理位置等元数据。同时，MongoDB的水平扩展能力和聚合查询功能可有效支持大规模数据管理。对于评论中的图片、视频等二进制文件，则通过对象存储（如Amazon S3或阿里云OSS）存储，结合预签名URL实现安全访问，避免数据库性能损耗。辅助索引层采用Elasticsearch同步关键字段，通过倒排索引和中文分词技术（如IK分词）实现秒级全文检索，并支持模糊搜索与高亮显示。

在场景化应用中，情感分析可通过多种技术实现：对于中文评论，SnowNLP或Hugging Face的BERT模型能精准识别情感倾向，例如通过预训练模型对“电池续航太差”等文本输出负面标签及置信度评分。评论分类则结合监督学习（如SVM、BERT）与无监督方法（如K-Means聚类），通过FastAPI构建实时分类服务或使用Spark进行批量处理。全文搜索功能由Elasticsearch支撑，通过MongoDB Connector实现实时数据同步，支持用户快速定位包含特定关键词的评论内容。主题模型则利用LDA、BERTopic等算法从海量评论中提取高频主题（如“屏幕质量”“物流服务”），并通过WordCloud等工具可视化呈现，帮助业务方洞察用户关注焦点。整个架构通过混合存储与多技术协同，在保证性能的同时实现成本优化。

应用场景

数据库选型的核心是：理解业务数据的生命周期，把握各类数据库的能力边界，在架构灵活性与技术可控性之间寻找最佳平衡点。任何脱离具体业务场景的数据库对比都是无效的，优秀的架构设计应当像精密钟表般，让每个齿轮（数据库）在最适合的位置发挥最大效能。

结合典型应用场景，什么场景应该用什么数据库呢？其实在一个业务场景下需要多种类数据库结合使用，总结如下：

我们以单个数据库为维度再分别讨论一下：

关系型:MySQL

MySQL：高并发事务系统（如电商订单处理）

核心场景：电商平台的订单系统，需要保证每笔交易的原子性（如扣减库存、生成订单、支付记录必须同时成功或回滚）。

为什么选择MySQL：

ACID事务支持：通过InnoDB引擎实现强一致性，确保订单状态的准确性。
复杂查询能力：支持多表JOIN（如查询用户历史订单及商品详情）。
成熟生态：主从复制、分库分表工具（如ShardingSphere）支持高可用和扩展。

对比其他数据库：

MongoDB：不支持跨文档事务（早期版本），不适合强一致性场景。
Redis：内存数据库，无法持久化复杂事务逻辑。

示例：每秒处理10万笔订单的电商平台，通过MySQL分库分表（按用户ID哈希）实现横向扩展。

搜索引擎：ES

Elasticsearch：实时商品搜索与日志分析

核心场景：电商平台商品搜索，用户输入关键词（如“防水运动鞋”）后毫秒级返回结果。

为什么选择Elasticsearch：

倒排索引：快速匹配关键词，支持分词、同义词扩展、模糊查询。
聚合分析：统计商品类目的平均评分、价格区间分布。
近实时（NRT）：新上架商品1秒内可被搜索。

对比其他数据库：

MySQL：全文索引性能差，无法支持高并发搜索。
MongoDB：文本搜索功能简单，缺乏分词器和相关性排序。

示例：某跨境电商平台，每日处理1亿次搜索请求，通过ES集群（分片+副本）实现99.9%的查询响应时间<50ms。

文档型：MongoDB

MongoDB：内容管理系统（CMS）与动态配置存储**

核心场景：新闻发布平台的文章存储，每篇文章包含标题、正文、多级评论、动态标签。

为什么选择MongoDB：

灵活文档模型：存储嵌套结构的JSON数据（如评论树形结构）。
水平扩展：通过Sharding自动分配数据到多个分片。
局部更新：修改文章某个字段无需重写整个文档。

对比其他数据库：

MySQL：需要拆分为多张表（文章表、评论表），JOIN查询效率低。
HBase：适合结构化扫描，不适合嵌套数据查询。

示例：某媒体平台存储1000万篇文章，每篇文章包含动态标签（如“科技, 2023趋势”），通过MongoDB的文档结构直接存储。

键值存储：Redis

Redis：高频访问缓存与会话管理

核心场景：社交平台的热门帖子缓存，用户访问时优先从缓存读取，减少数据库压力。

为什么选择Redis：

内存存储：读写延迟<1ms，支持每秒百万级操作。
数据结构丰富：使用Sorted Set存储热门帖子排行榜，Hash存储用户会话信息。
持久化可选：RDB快照或AOF日志保障数据安全。

对比其他数据库：

MySQL：磁盘存储，无法满足毫秒级响应。
MongoDB：内存占用高，不适合纯缓存场景。

示例：某论坛每日活跃用户500万，通过Redis缓存前1000热门帖子，命中率90%，数据库负载下降70%。

宽列存储：HBase、Cassandra

HBase：海量时序数据存储（如物联网设备监控）

核心场景：电力公司存储智能电表每秒采集的电流、电压数据。

为什么选择HBase：

列族存储：按列压缩时序数据，节省存储空间。
随机读写：按设备ID+时间戳快速查询某时刻数据。
HDFS集成：数据自动下沉至HDFS实现低成本归档。

对比其他数据库：

Cassandra：适合跨数据中心写入，但单点查询性能不如HBase。
MySQL：无法支持每秒百万级数据写入。

示例：某物联网平台每日新增1TB传感器数据，通过HBase的RowKey设计（设备ID+时间戳）实现毫秒级查询。

Cassandra：多数据中心日志同步（如全球化应用）

核心场景：跨国社交应用的聊天日志存储，要求数据在欧美亚三地就近写入且最终一致。

为什么选择Cassandra：

多活架构：数据自动复制到多个数据中心，写入本地即成功。
高吞吐写入：LSM树引擎支持每秒百万级写入。
无单点故障：去中心化架构避免主从瓶颈。

对比其他数据库：

HBase：依赖HDFS和ZooKeeper，扩展性受限。
MySQL：主从复制跨地域延迟高。

示例：某IM应用每日处理50亿条消息，通过Cassandra实现三地数据中心写入延迟<10ms。

数据仓库：Hive

Hive：离线数据仓库与ETL批处理

核心场景：零售企业每月销售数据的批量清洗与报表生成。

为什么选择Hive：

SQL兼容：通过HiveQL实现类SQL查询，降低学习成本。
海量数据批处理：基于MapReduce或Tez引擎处理TB级数据。
低成本存储：数据存储在HDFS，支持压缩格式（ORC、Parquet）。

对比其他数据库：

ClickHouse：适合实时分析，但存储成本高。
MySQL：无法处理PB级数据。

示例：某电商每月分析10TB历史订单数据，通过Hive生成“年度区域销售趋势”报表，耗时2小时。

列式存储：ClickHouse

ClickHouse：实时OLAP与用户行为分析

核心场景：广告平台的实时点击流分析，每日处理千亿级事件，生成实时报表。

为什么选择ClickHouse：

列式存储：压缩率高，适合聚合计算（如SUM、COUNT）。
向量化执行：利用CPU SIMD指令加速查询。
实时写入：支持Kafka直接导入数据，延迟低至秒级。

对比其他数据库：

Hive：批处理模式，查询延迟分钟级。
MySQL：无法支撑海量数据聚合。

示例：某广告平台分析每日200亿次点击事件，通过ClickHouse集群实现“过去1小时各渠道转化率”秒级响应。

图数据库：Neo4j

Neo4j：社交网络关系挖掘（如好友推荐）

核心场景：社交平台的“六度关系”分析，计算用户A到用户B的最短路径。

为什么选择Neo4j：

图遍历优化：通过原生图存储引擎高效遍历多跳关系。
Cypher查询语言：直观表达复杂关系模式（如查找共同好友）。
实时更新：支持动态添加节点和边。

对比其他数据库：

MySQL：需递归JOIN，性能随跳数指数级下降。
MongoDB：无法直接表达关系网络。

示例：某社交平台分析10亿用户关系，Neo4j可在毫秒级返回“用户A的三度人脉中可能认识的人”。

总结

事务强一致 → MySQL
实时搜索 → Elasticsearch
动态文档 → MongoDB
高频缓存 → Redis
实时OLAP → ClickHouse
时序海量存储 → HBase
全球化写入 → Cassandra
关系网络 → Neo4j
离线批处理 → Hive

最后总结

**数据模型的本质差异是选型的第一道分水岭。**关系型数据库（如MySQL、PostgreSQL）建立在严格的二维表结构之上，通过外键约束和范式理论保障数据完整性。这种结构特别适合需要复杂关联查询的财务系统、ERP等业务场景。例如银行转账操作需要严格遵循ACID事务原则，MySQL的InnoDB引擎通过行级锁和MVCC机制实现事务隔离，配合主从复制架构可以满足多数金融级需求。但在物联网设备日志存储场景下，每天千万级的写入请求会导致关系型数据库的索引维护成本急剧上升，此时文档型数据库MongoDB的BSON自由格式和分片集群优势便显现出来。MongoDB的写操作默认不等待磁盘确认，通过内存映射文件实现高速写入，特别适合内容管理系统或实时分析场景中半结构化数据的快速摄入。

分布式架构的CAP权衡直接影响系统可用性。 Elasticsearch作为分布式搜索引擎，其倒排索引结构对文本检索的优化已达到毫秒级响应，在电商商品搜索、日志分析等场景具有不可替代性。但ES的强一致性模型可能导致集群脑裂风险，需要结合zen discovery机制进行节点状态管理。相比之下，HBase作为Hadoop生态的列式存储，通过RegionServer的水平扩展和LSM树的写入优化，能够承载PB级数据量的实时读写。某智慧城市项目曾使用HBase存储数十亿条交通卡口数据，利用其行键有序分布特性实现车辆轨迹的快速回溯，这是传统关系型数据库难以企及的吞吐能力。

计算与存储的分离趋势重构了数据分析范式。 Hive建立在HDFS之上的元数据管理机制，通过类SQL语法实现大数据集的离线分析，其分区表和桶表的设计显著提升了TB级数据查询效率。某电商平台的历史订单分析采用Hive进行月度销售统计，配合Tez执行引擎将任务耗时从小时级压缩到分钟级。但Hive的高延迟特性使其不适合实时查询场景，这正是ClickHouse等OLAP数据库的突破方向。需要特别注意的是，数据湖架构的兴起使得Delta Lake、Hudi等解决方案开始融合事务管理和批流一体处理，这对传统数仓选型提出了新的挑战。

**事务完整性与系统弹性的平衡艺术。**当业务需要跨数据库操作时，如电商订单系统同时涉及MySQL库存扣减和MongoDB订单日志记录，分布式事务管理就成为关键挑战。Saga模式通过补偿机制实现最终一致性，而Seata框架的AT模式能在业务侵入性较低的情况下保障事务边界。但在高并发场景下，这类方案的性能损耗可能达到20%-30%，这就需要架构师在一致性级别和系统吞吐之间做出权衡。例如社交平台的点赞功能更适合使用Redis的原子计数器，完全放弃强一致性以换取百万级QPS的处理能力。

**硬件成本与运维复杂度的隐藏成本。**云原生时代，AWS Aurora通过计算存储分离架构实现了MySQL兼容数据库的自动扩缩容，其存储层可自动扩展到128TB，这种托管服务显著降低了运维负担。但对于需要定制化优化的场景，如金融行业的风控模型计算，仍需要基于物理机部署的Oracle RAC集群来保障IOPS性能。开源方案的隐性成本同样不容忽视，Elasticsearch集群的JVM堆内存配置直接影响索引性能，不当的分片设置可能导致磁盘空间浪费，这需要运维团队积累足够的调优经验。

在具体选型实践中，建议采用四维评估法：首先明确数据结构化程度（结构化、半结构化、非结构化），其次分析读写比例和并发量级，再次确定一致性要求（强一致、最终一致），最后考量扩展性和生态集成需求。例如智能穿戴设备数据采集场景，设备标识符作为MongoDB文档的天然主键，时间序列数据采用嵌套文档存储，既避免了关系型数据库的表关联开销，又利用TTL索引实现自动过期清理。而在用户画像分析场景，HBase 的宽表结构可以存储数千个用户标签，配合Phoenix的SQL层实现灵活查询，这种架构组合充分发挥了列式存储的高压缩比优势。

最后我们用一个简单的流程图来说明一下这个选型过程：

Redis6.0 以后为什么使用了多线程？

Mon, 18 Nov 2024 02:04:32 +0000

Redis 所谓的单线程并不是所有工作都是只有一个线程在执行，而是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，Redis 在处理客户端的请求时包括获取 (socket 读）、解析、执行、内容返回 (socket 写）等都由一个顺序串行的主线程处理。

这就是所谓的“单线程”。这也是 Redis 对外提供键值存储服务的主要流程。由于 Redis 在处理命令的时候是单线程作业的，所以会有一个 Socket 队列，每一个到达的服务端命令来了之后都不会马上被执行，而是进入队列，然后被线程的事件分发器逐个执行。如下图：

至于 Redis 的其他功能，比如持久化、异步删除、集群数据同步等等，其实是由额外的线程执行的。可以这么说，Redis 工作线程是单线程的。但是在 4.0 之后，对于整个 Redis 服务来说，还是多线程运作的。

6.0 之前为什么要使用单线程

在使用 Redis 时，Redis 主要受限是在内存和网络上，CPU 几乎没有性能瓶颈的问题。
以 Linux 系统为例子，在 Linux 系统上 Redis 通过 pipelining 可以处理 100w 个请求每秒，而应用程序的计算复杂度主要是 O(N) 或 O(log(N)) ，不会消耗太多 CPU。
使用了单线程后，提高了可维护性。多线程模型在某些方面表现优异，却增加了程序执行顺序的不确定性，并且带来了并发读写的一系列问题，增加了系统复杂度。同时因为线程切换、加解锁，甚至死锁，造成一定的性能损耗。
Redis 通过 AE 事件模型以及 IO 多路复用等技术，拥有超高的处理性能，因此没有使用多线程的必要

6.0 之后的多线程主要解决什么问题

近年来底层网络硬件性能越来越好，Redis 的性能瓶颈逐渐体现在网络 I/O 的读写上，单个线程处理网络 I/O 读写的速度跟不上底层网络硬件执行的速度。

Redis 在处理网络数据时，调用 epoll 的过程是阻塞的，这个过程会阻塞线程。如果并发量很高，达到万级别的 QPS，就会形成瓶颈，影响整体吞吐能力

既然读写网络的 read/write 系统调用占用了 Redis 执行期间大部分 CPU 时间，那么要想真正做到提速，必须改善网络 IO 性能。我们可以从这两个方面来优化：

提高网络 IO 性能，典型实现方式比如使用 DPDK 来替代内核网络栈的方式
使用多线程，这样可以充分利用多核 CPU，同类实现案例比如 Memcached。

协议栈优化的这种方式跟 Redis 关系不大，所以最便捷高效的方式就是支持多线程。总结起来，redis 支持多线程就是以下两个原因：

可以充分利用服务器 CPU 的多核资源，而主线程明显只能利用一个
多线程任务可以分摊 Redis 同步 IO 读写负荷，降低耗时

6.0 版本优化之后，主线程和多线程网络 IO 的执行流程如下：

具体步骤如下：

主线程建立连接，并接受数据，并将获取的 socket 数据放入等待队列；
通过轮询的方式将 socket 读取出来并分配给 IO 线程；
之后主线程保持阻塞，一直等到 IO 线程完成 socket 读取和解析；
I/O 线程读取和解析完成之后，返回给主线程，主线程开始执行 Redis 命令；
执行完 Redis 命令后，主线程阻塞，直到 IO 线程完成结果回写到 socket 的工作；
主线程清空已完成的队列，等待客户端新的请求。

本质上是将主线程 IO 读写的这个操作独立出来，单独交给一个 I/O 线程组处理。这样多个 socket 读写可以并行执行，整体效率也就提高了。同时注意 Redis 命令还是主线程串行执行。

利用多核来分担 I/O 读写负荷。在事件处理线程每次获取到可读事件时，会将所有就绪的读事件分配给 I/O 线程，并进行等待，在所有 I/O 线程完成读操作后，事件处理线程开始执行任务处理，在处理结束后，同样将写事件分配给 I/O 线程，等待所有 I/O 线程完成写操作。

 1int handleClientsWithPendingReadsUsingThreads(void) {
 2 ...
 3 /* Distribute the clients across N different lists. */
 4 listIter li;
 5 listNode *ln;
 6 listRewind(server.clients_pending_read,&li);
 7 int item_id = 0;
 8 // 将等待处理的客户端分配给 I/O 线程
 9 while((ln = listNext(&li))) {
10 client *c = listNodeValue(ln);
11 int target_id = item_id % server.io_threads_num;
12 listAddNodeTail(io_threads_list[target_id],c);
13 item_id++;
14 }
15 ...
16 /* Wait for all the other threads to end their work. */
17 // 轮训等待所有 I/O 线程处理完
18 while(1) {
19 unsigned long pending = 0;
20 for (int j = 1; j < server.io_threads_num; j++)
21 pending += io_threads_pending[j];
22 if (pending == 0) break;
23 }
24 ...
25 return processed;
26}

本质上是利用多核的多线程让多个 IO 的读写加速。

局限性

6.0 版本的多线程并非彻底的多线程，I/O 线程只能同时执行读或者同时执行写操作，期间事件处理线程一直处于等待状态，并非流水线模型，有很多轮训等待开销。

Milvus实战：如何用一个数据库提升你的AI项目性能

Fri, 11 Oct 2024 08:22:08 +0000

回顾

在上一文中我们使用 LlamaIndex 整合智谱 AI 的 GLM-4 和 Embedding-3 模型一起构建 RAG 应用。

在上篇文章的最后，我们发现因为 Embedding-3 模型是同步调用的，所以从测试效果看比较慢。每一次运行都产生了大量的 http 同步请求。文末我说解决的办法可以在本地部署一个开源的 embedding 模型，这样就不会产生远程的 http 调用了，而且也比较省钱。

这是个办法，但实际上还有其他的好办法。

我们可以将文档通过 embedding 模型产生的向量存储起来，这样相同的文档，只有在第一次 embedding 时会慢一些，再次检索时，可以快速地将已经保存好的向量查询出来使用。

本地文件存储

利用 LlamaIndex 的 API ，我们可以非常方便地把向量存储到本地文件，以下是一个例子，我把向量存储到项目的 index目录下：

 1def load_or_create_index():
 2
 3 # 检查是否存在有效的持久化索引
 4 if (
 5 os.path.exists("index")
 6 and os.path.isdir("index")
 7 and any(file.endswith(".json") for file in os.listdir("index"))
 8 ):
 9 print("正在加载现有索引。..")
10 storage_context = StorageContext.from_defaults(persist_dir="index")
11 index = load_index_from_storage(storage_context)
12 else:
13 print("未找到有效的现有索引，正在创建新索引。..")
14 # 使用预定义的 DATA_DIR 常量
15 documents = SimpleDirectoryReader("./data").load_data()
16 # 创建新索引，显示 embedding 进度
17 index = VectorStoreIndex.from_documents(documents, show_progress=True)
18 # 持久化索引
19 index.storage_context.persist(persist_dir="index")
20 print("索引已创建并保存到本地。")
21
22 return index

看起来代码多，实际上重要的就是这两行：

1storage_context = StorageContext.from_defaults(persist_dir="index")
2index = load_index_from_storage(storage_context)

也很容易理解，见文知意。

索引创建后，index 会自动创建一些文件来保存向量信息：

向量数据库

一般情况下，比如小型项目，将向量数据保存在系统文件中就已经够用了。但是，在中大型项目中，由于数据规模较大，使用人数较多，为了方便管理和扩展，我们会使用专业的向量数据库来存储和管理向量数据。

你可以借助下图了解下向量数据库在 AIGC 应用架构中的位置和作用

向量数据库选型

“

RAG 系统的成功在很大程度上取决于其高效地获取和处理海量信息的能力。向量数据库又在其中发挥了不可替代的作用，并构成了 RAG 系统的核心

不看不知道，作为一个数据库软件，目前向量数据库领域是真卷啊，打眼一看至少有几十个。知名的也得有 10 几个。

说实话，最开始还真有些茫然，有点儿挑花眼了，我们这里列举几个知名的向量数据库：

Milvus 是一个 2019 年开源的纯向量数据库，号称全球最先进的开源向量数据库。它是 LF AI & Data Foundation（简称 LFAI，它相当于 CNCF 在云原生界的地位）赞助的毕业项目
Chroma 是一个相对较新的向量数据库，目前它的设计确实是以单节点模式为主，主要用于中小型应用或开发测试环境。然而，对于需要更高可用性和横向扩展能力的生产环境，Chroma 当前的版本可能还不完全满足需求。Chroma 内置了 SQLite 作为其底层存储引擎
Weaviate ：是一个云原生的、开源的向量数据库。专为大规模的向量数据存储和检索设计。它结合了向量搜索和图数据库的优势，适用于机器学习、推荐系统、图像识别和自然语言处理等场景。
Faiss ：由 Facebook AI Research 开发的 Faiss 是一个开源库，用于快速、密集向量相似性搜索和分组
Qdrant 是一个开源的向量数据库，专为高效的大规模向量数据存储和检索设计。它适用于机器学习、推荐系统、图像识别和自然语言处理等场景，提供了高性能和易用性的结合。
PGVector 是一个基于 PostgreSQL 的扩展插件，旨在提供强大的向量存储和查询功能，PGVector 可以无缝集成到现有的 PostgreSQL 数据库中，用户无需迁移现有的数据库即可开始使用向量搜索功能。因为是 PostgreSQL 插件，借助 PostgreSQL 的长期开发和优化，PGVector 继承了其可靠性和稳健性，同时在向量化处理方面进行了增强。

整体上看在向量数据库领域有这么几类玩家：

专做向量数据库的，大部分是开源的，如 Chroma、Weaviate 等
做关系型数据库的扩展或插件，如 PGVector
做 NoSQL 数据库的功能扩展或兼容，如 Elasticsearch、 Redis、 ClickHouse 等

太多了，真是太多了，最开始我做选型的时候真是有点儿挑花眼了。最后，一点点缩小范围，最终进入决赛圈的是：

Qdrant
Weaviate
Milvus

你可以通过 https://zilliz.com.cn/comparison 来了解各向量数据库之间的对比情况

最终我选择了 Milvus 原因是：

它确实很知名，看了那么多评测，各方面性能都很能打
我个人觉得比较重要的是它还有数据库管理客户端 attu

向量数据库不像我之前使用过的关系型数据库，一般是没有像 Navicat 、DataGrip 这样的数据库管理客户端的。一般只有 CRUD 接口或 CLI 客户端。这对于初学者了解和学习向量数据库不太友好，所以我还是特别希望有这样一个有 GUI 图形界面、看得见摸得着的客户端的，而 Milvus 正好是有的。就是 attu （可以通过 https://github.com/zilliztech/attu 下载）

如果你也和我一样在 Qdrant、Weaviate、Milvus 之间纠结的话，可以参考网上一位大哥对它们的评价：“总结起来就是，Qdrant 开销特别小，Weaviate 支持向量搜索、对象存储和倒排索引的组合，Milvus 性能最强、花活最多。”

Chroma

LlamaIndex 官方的例子使用的是 Chroma 作为向量数据库进行向量存储。

默认情况下，Chroma 会将向量数据存储在本地文件系统中。我们就以 Chroma 为例写个例子。

Chroma 不需要安装外部软件，安装导入相关的库就可了

1import chromadb
2from llama_index.vector_stores.chroma import ChromaVectorStore

在导入了 Chroma 相关的库后，我们将 load_or_create_index() 方法调整一下：

 1def load_or_create_index():
 2 
 3 # 初始化客户端，设置数据保存路径
 4 db = chromadb.PersistentClient(path="./chroma_db")
 5 # 创建或获取集合
 6 chroma_collection = db.get_or_create_collection("quickstart")
 7 # 将 chroma 指定为上下文的 vector_store
 8 vector_store = ChromaVectorStore(chroma_collection=chroma_collection)
 9 storage_context = StorageContext.from_defaults(vector_store=vector_store)
10
11 # 检查集合是否为空
12 if chroma_collection.count() == 0:
13 # 如果集合为空，加载文档并创建新的索引
14 documents = SimpleDirectoryReader("./data").load_data()
15 index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
16 print("已创建新的索引")
17 else:
18 # 如果集合不为空，直接从 vector_store 加载索引
19 index = VectorStoreIndex.from_vector_store(vector_store, storage_context=storage_context)
20 print("已加载现有索引")
21
22 return index

可以看到也很简单。程序运行后，chroma_db 文件夹下会自动创建以下文件：

前文中我们提到过 chroma 内置了 SQLite ，这里就体现出来了。

Milvus

在使用 Milvus 前我们需要先安装它。它有多种安装方式，我本地通过 Docker-Compose 安装

 1version: '3.5'
 2
 3services:
 4 etcd:
 5 container_name: milvus-etcd
 6 image: quay.io/coreos/etcd:v3.5.14
 7 environment:
 8 - ETCD_AUTO_COMPACTION_MODE=revision
 9 - ETCD_AUTO_COMPACTION_RETENTION=1000
10 - ETCD_QUOTA_BACKEND_BYTES=4294967296
11 - ETCD_SNAPSHOT_COUNT=50000
12 volumes:
13 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd
14 command: etcd -advertise-client-urls=http://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd
15 healthcheck:
16 test: ["CMD", "etcdctl", "endpoint", "health"]
17 interval: 30s
18 timeout: 20s
19 retries: 3
20
21 minio:
22 container_name: milvus-minio
23 image: minio/minio:RELEASE.2023-03-20T20-16-18Z
24 environment:
25 MINIO_ACCESS_KEY: minioadmin
26 MINIO_SECRET_KEY: minioadmin
27 ports:
28 - "9001:9001"
29 - "9000:9000"
30 volumes:
31 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data
32 command: minio server /minio_data --console-address ":9001"
33 healthcheck:
34 test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
35 interval: 30s
36 timeout: 20s
37 retries: 3
38
39 standalone:
40 container_name: milvus-standalone
41 image: milvusdb/milvus:v2.3.0
42 command: ["milvus", "run", "standalone"]
43 security_opt:
44 - seccomp:unconfined
45 environment:
46 MINIO_REGION: us-east-1
47 ETCD_ENDPOINTS: etcd:2379
48 MINIO_ADDRESS: minio:9000
49 volumes:
50 - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
51 healthcheck:
52 test: ["CMD", "curl", "-f", "http://localhost:9091/healthz"]
53 interval: 30s
54 start_period: 90s
55 timeout: 20s
56 retries: 3
57 ports:
58 - "19530:19530"
59 - "9091:9091"
60 depends_on:
61 - "etcd"
62 - "minio"
63
64networks:
65 default:
66 name: milvus

安装好以后，可以看到它内部有三个容器：

接着我们安装 attu，它的安装比较简单，下载相关平台的安装文件安装即可

attu 安装完成后打开进行 Milvus 的连接：

默认地址是 127.0.0.1:19530

接着，我们来到程序这里，进行连接和使用，同样，要先导入库

1from llama_index.vector_stores.milvus import MilvusVectorStore

然后我们调整一下之前的方法，改写一个新的方法来连接 Miluvs:

 1def get_or_create_index(is_create: bool = False):
 2 """
 3 获取或创建索引
 4 overwrite 设置为 False 意味着如果同名的集合已存在，将不会覆盖它。
 5 dim 是向量维度，必须与 embedding 模型的维度一致。
 6 """
 7 vector_store = MilvusVectorStore(
 8 uri="http://localhost:19530",
 9 dim=256,
10 overwrite=False,
11 collection_name="llamaindex_collection",
12 )
13
14 if is_create:
15 storage_context = StorageContext.from_defaults(vector_store=vector_store)
16 documents = SimpleDirectoryReader("./data").load_data()
17 index = VectorStoreIndex.from_documents(
18 documents, storage_context=storage_context
19 )
20 print("已成功创建并存储新的索引。")
21 else:
22 index = VectorStoreIndex.from_vector_store(vector_store)
23
24 return index

我相信如果你阅读了前文，知道这段代码的重要点在哪里。

当 RAG 应用程序正常运行后，向量数据就被存储到了 Milvus 数据库中：

有了 GUI 界面，就比较直观地能感受到向量数据是个什么样子了。

有关在 attu 中进行向量数据的查询等操作可以参数相关文档，本文就不多说了。

使用向量数据库存储以后，我们再次运行查询，速度就很快了，因为第一次运行的时候就已经把文档 embedding 后的向量存储起来了，只需要从 Milvus 中加载查询就可以了，不用再走 http 远程调用。

总结

在本文中，我们深入探讨了如何通过 LlamaIndex 整合智谱 AI 的 GLM-4 和 Embedding-3 模型来构建 RAG 应用，并针对 Embedding-3 模型同步调用导致的性能瓶颈问题，提出了有效的解决方案。我们发现，将文档的向量存储起来，可以显著提高检索速度，避免了重复的 HTTP 同步请求，从而节省了成本和时间。

通过本地文件存储和向量数据库的选型，我们对比了多种向量数据库的特点和性能，最终选择了 Milvus 作为我们的向量数据库。Milvus 以其卓越的性能和易用性脱颖而出，特别是其数据库管理客户端 attu，为初学者提供了友好的图形界面，使得向量数据库的管理和操作变得更加直观和便捷。

在实际应用中，我们通过 Docker-Compose 安装了 Milvus，并利用 attu 进行了连接和操作。通过将向量数据存储到 Milvus 数据库中，我们显著提高了查询速度，因为文档的向量在第一次运行时就已经被存储起来，后续的查询可以直接从 Milvus 中加载，无需再次进行远程 HTTP 调用。

此外，我们还探讨了使用 Chroma 作为向量数据库的方案，它内置了 SQLite，简化了安装和使用过程。通过 LlamaIndex 的 API，我们可以轻松地将向量存储到本地文件或 Chroma 数据库中，进一步增强了 RAG 应用的性能和可扩展性。

总的来说，通过本文的探讨和实践，我们不仅解决了 RAG 应用中的性能问题，还为中大型项目提供了一种高效、可扩展的向量数据存储和管理方案。随着 AI 技术的不断发展，向量数据库在 AIGC 应用架构中的作用将越来越重要，而 Milvus 等向量数据库的选择和应用，将为构建更加智能和高效的 AI 应用提供强有力的支持。

本文所涉及的完整代码在该项目中：https://github.com/xiaobox/llamaindex_test 大家可按需自取

关于 Redis 的有趣的知识

Fri, 01 Dec 2023 08:25:22 +0000

关于 Redis 的有趣的知识

有序集合的英文全称明明是 sorted sets，为啥叫 zset 呢？

Redis官网上没有解释，但是在 Github 上有人向作者提问了。

作者是这么回答的：

Hello. Z is as in XYZ, so the idea is, sets with another dimension: the order. It’s a far association… I know 😃

原来前面的 Z 代表的是 XYZ 中的Z，zset 是在说这是比 set 有更多一个维度的 set 😦

是不没道理？

更没道理的还有，Redis 默认端口 6379 ，因为作者喜欢的一个叫 Merz 的女明星，其名字在手机上输入正好对应号码 6379，索性就把 Redis 的默认端口叫 6379 了…

小盒子的技术分享

跟着 Guava 学 Java 之缓存

Wed, 21 Sep 2022 14:42:09 +0000

本文我们先介绍一些缓存的背景知识，以及内存缓存的流行开源库类实现，最后利用一些例子重点介绍下 Guava Cache 的缓存功能。

背景

什么是缓存

“

在计算中，缓存是一个高速数据存储层，其中存储了数据子集，且通常是短暂性存储，这样日后再次请求该数据时，速度要比访问数据的主存储位置快。通过缓存，可以高效地重用之前检索或计算的数据。

”

本文中所提及的缓存主要是指内存缓存，跟硬件没什么关系（比如三级缓存什么的），主要是应用代码层面和内存交互的这部分。

缓存的特点

第一个特点：贼快（操作内存读写当然快了）

你可能会问了，贼快是多快？嗯，没有对比就没有伤害，我们来看一下不同介质访问数据的时间情况

看到了吧，RAM 的速度大概是 10-100 纳秒，什么概念？ 1 秒钟等于 10 亿纳秒，这速度快到你根本感觉不到。

第二个特点：说没就没

断电立即丢失
超过缓存失效时间

解决什么问题

一般来说，我们利用本地的内存缓存主要可以达到减轻数据库压力、提高系统响应速度和吞吐量的目的。

总之，如果对某些值的计算或检索成本很高，并且多次需要使用该值时，应该考虑使用缓存。

内存缓存库类

在 Java 中一提到缓存，我们首先想到的可以用 ConcurrentHashMap做缓存。

1static ConcurrentHashMap<String,Object> localCache = new ConcurrentHashMap<>();

为什么要用 ConcurrentHashMap 呢？

因为首先它是个 Map，这种 K,V 的数据结构很适合用来读写缓存对象，其次它还是线程安全的，多线程并发不会有线程安全问题。

Java 虽然为我们提供了ConcurrentHashMap 这样合适做缓存的数据结构，但他在功能上却有很多的不足，比如没有回收、驱逐、监听、刷新等功能。一般来说，我们设计一套完整的缓存方案虽然这些功能，用 ConcurrentHashMap意味着这些功能你要自己开发了。

在 Java 的生态中有许多库可以帮助我们省去自己开发的麻烦，人家都封装好了，开箱即用，这里我们列举几个知名和常用的，后面我们重点介绍 Guava 的 cache 模块：

Guava Cache
Spring Cache Spring 提供的一整套的缓存解决方案。虽然它本身并没有提供缓存的实现，但是它提供了一整套的接口和代码规范、配置、注解等，这样它就可以整合各种缓存方案了，比如 Redis、Ehcache，我们也就不用关心操作缓存的细节。
Caffeine（以 GuavaCache 为原型而开发的一个本地缓存框架，相对 GuavaCache, 它有更高的性能与命中率，更强大的功能，更灵活的配置方式）
J2Cache（OSChina 开源的一个两级缓存框架，采用固定的一级 + 二级缓存的模式，从一开始就是为了解决两级缓存一致性的问题）
JetCache（是阿里开源的通用缓存访问框架，它统一了多级缓存的访问方式，封装了类似于 SpringCache 的注解，以及 GuavaCache 类似的 Builder, 来简化项目中使用缓存的难度）

这里多说两句：

Caffeine是当前最优秀的内存缓存框架，不论读还是写的效率都远高于其他缓存，而且在Spring5开始的默认缓存实现就将 Caffeine 代替原来的 Guava。

在项目中，比如你用 SpringBoot 想加本地缓存，我们通常会引入 SpringCache+Caffeine的依赖。使用 SpringCache 注解方法实现缓存。SpringCache 帮我们封装了 Caffeine，通过这种方式集成 Caffeine。

1<dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-cache</artifactId>
4</dependency>
5<dependency>
6 <groupId>com.github.ben-manes.caffeine</groupId>
7 <artifactId>caffeine</artifactId>
8</dependency>

有朋友说了，你这是一级缓存，我们一般会使用二级缓存，即一级缓存用 caffeine 二级缓存用 Redis(强强联合，很常用的方案)，一级缓存找不到去二级缓存找。

没错，如果你想用 SpringBoot 集成 Caffeine和Redis实现二级缓存，有两种方式：

第一种，直接集成，引入的依赖有变化：

 1
 2 <dependency>
 3 <groupId>org.springframework.boot</groupId>
 4 <artifactId>spring-boot-starter-cache</artifactId>
 5 </dependency>
 6 <dependency>
 7 <groupId>com.github.ben-manes.caffeine</groupId>
 8 <artifactId>caffeine</artifactId>
 9 </dependency>
10 <dependency>
11 <groupId>org.springframework.boot</groupId>
12 <artifactId>spring-boot-starter-data-redis</artifactId>
13 </dependency>

这里顺便说一下 spring-boot-starter-data-redis ，spring-data-redis 和 Redis 的关系如下图，延续了 Spring 的一贯思想，对上层仍然是一层封装，对底层支持各种 Redis 客户端的实现。

第一种方式的集成比较简单，但请注意 spring cache (caffeine) 和 spring-data-redis(redis)，是各管各的（如前面括号里写的），不好意思，一二级缓存之间的逻辑关系需要你自己处理具体来说比如你可以实现 cache 拦截器 CacheInterceptor

这里有一个比较容易混乱的点， spring cache 是支持多个 Provider 的：

Generic
JCache (JSR-107) (EhCache 3, Hazelcast, Infinispan, and others)
EhCache 2.x
Hazelcast
Infinispan
Couchbase
Redis
Caffeine
Simple

意思是我们用 springcache 即可以集成 Caffeine 这种本地缓存，也可以集成 Redis 这种分布式缓存，当然配置肯定不一样。但你要清楚，同时只能集成一个，没有说用 springcache 能同时集成两个的，上面讲的集成二级缓存（caffeine+redis），是指各管各的，springcache 集成 Caffeine，spring-data-redis 集成 redis。

刚才说了第一种集成方式，现在说第二种，即利用 jetCache 做二级缓存的集成，这里依赖有了很大变化：

1 <dependency>
2 <groupId>com.alicp.jetcache</groupId>
3 <artifactId>jetcache-starter-redis-lettuce</artifactId>
4 <version>2.6.3</version>
5</dependency>

只需要这一个依赖，不需要 spring-cache 和 spring-data-redis 了，因为 jetCache 里面已经引入了 caffeine 和 lettuce 的包了。

这并不是说 spring-data-redis 和 spring-cache 不能引入，可以用，如果你有需求，但要注意检查依赖的冲突和重复。

 1jetcache:
 2 statIntervalMinutes: 1
 3 areaInCacheName: false
 4 local:
 5 default:
 6 type: caffeine
 7 keyConvertor: fastjson2
 8 remote:
 9 default:
10 type: redis.lettuce
11 keyConvertor: fastjson2
12 broadcastChannel: projectA
13 keyPrefix: projectA
14 valueEncoder: java
15 valueDecoder: java
16 uri: redis://127.0.0.1:6379/
17 defaultExpireInMillis: 5000

我们从上面的配置中可以看出，很明显这里配置了二级缓存，分别是 local 和 remote，由于 jetCache 支持二级缓存的操作，就不用我们自己写代码实现了，不过值得注意的是，要实现分布式两级缓存的同步因为太重，框架没做得自己实现，关于这个问题可以参考（https://github.com/alibaba/jetcache/issues/205）

Guava 缓存

终于到我们今天的主角 Guava Cache 了，无论你对 Caffeine 和 JetCache 多么感兴趣，请都先克制和忍耐一下，把 Guava 的 cache 看完，毕竟 Caffeine 也是以 Guava 为原型而产生的框架。

这里我们再次强调** Guava Cache 指的本地缓存，即数据存储在当前应用服务器的内存之中，而像 Redis 这样的分布式缓存，数据是存储在应用服务器内存之外的**。

下面我们来具体说说 Guava 的 Cache 怎么用

加载

cache loading , 即缓存的加载或者创建有两种方式：

cacheLoader
callable

我们首先说一下 cacheLoader ，举个例子：

 1 LoadingCache<String, String> cahceBuilder = CacheBuilder
 2 .newBuilder()
 3 .build(new CacheLoader<String, String>() {
 4 @Override
 5 public String load(String key) throws Exception {
 6 return "no " + key + "!";
 7 }
 8
 9 });
10
11 cahceBuilder.put("name", "jack");
12 cahceBuilder.put("id", "123");
13
14 System.out.println(cahceBuilder.get("name"));
15 System.out.println(cahceBuilder.get("id"));
16 System.out.println(cahceBuilder.get("address"));
17 System.out.println(cahceBuilder.getAll(List.of("name","id","address")));

输出：

1jack
2123
3no address!
4{name=jack, id=123, address=no address!}

上面的小例子我们用 cacheBuilder 构造出来的 LoadingCache 来存取类型均为String 的 K,V 缓存。build 方法需要传入一个 CacheLoader 对象，CacheLoader 是一个抽象类，需要重写 load 方法。这个 load 的方法的作用是：如果我们调用 LoadingCache 中的 get 方法，缓存不存在相对应的 key 的数据，那么 CacheLoader 会自动调用 load 方法加载数据进来，至于数据从哪里来是你自己设计的，比如从数据库或者 Redis 等等。

关于最后的 getAll 方法： getAll(Iterable<? extends K>) 方法用来执行批量查询。默认情况下，对每个不在缓存中的键，getAll 方法会单独调用 CacheLoader.load 来加载缓存项。如果批量的加载比多个单独加载更高效，你可以重载 CacheLoader.loadAll 来利用这一点。getAll(Iterable) 的性能也会相应提升。

关于 LoadingCache ，我们看一下它的特点：

“

A semi-persistent mapping from keys to values. Values are automatically loaded by the cache, and are stored in the cache until either evicted or manually invalidated. The common way to build instances is using CacheBuilder. Implementations of this interface are expected to be thread-safe, and can be safely accessed by multiple concurrent threads.

”

一种半持久化的 KV 结构
这些 KV 会一直有效，直到被驱逐或者手动设置为无效
线程安全的

接着我们来看一下 callable ，举个简单例子：

 1 Cache<String, String> cache = CacheBuilder.newBuilder().build();
 2
 3 String name = cache.get("name", new Callable<String>() {
 4 @Override
 5 public String call() throws Exception {
 6
 7 return "jack";
 8 }
 9 });
10 
11 System.out.println(name);
12
13 cache.put("id","123");
14 
15 System.out.println(cache.getIfPresent("id"));
16 System.out.println(cache.getIfPresent("address"));

输出：

1jack
2123
3null

可以看到 Callable 只有在缓存值不存在时，才会调用，值存在则直接返回该值。

总结

LoadingCache 继承了 Cache 接口。LoadingCache 读取一个指定 key 的数据时，如果 key 不存在，LoadingCache 会执行加载数据到缓存。（相当于全局的）
cacheloader 的定义比较宽泛，是针对整个 cache 定义的，可以认为是统一的根据 key 值 load value 的方法。而 callable 的方式较为灵活，允许你在 get 的时候指定。（相当于个体自定义的）

其实无论是 LoadingCache 还是 callable 的方式加载缓存，他们都实现了一个共同的语义，即 “get-if-absent-compute” 获取缓存-如果没有-则计算。注意这个语义是原子的，通过下图看到底层源码，是加了锁的。

Java 中与此相似的原子语义有：ConcurrentHashMap 中的 putIfAbsent 和 computeIfAbsent，注意只是结构相似而已。

缓存回收

从大的方面讲缓存的回收分两种，一种是手动回收，一种是自动回收。手动回收就是你自己调方法干掉它，自动就是根据一定的规则约定，当到达触发条件自动回收。

我们先来看自动这部分。

Guava Cache 提供了三种基本的缓存回收方式：基于容量回收、定时回收和基于引用回收。

基于容量的回收（size-based eviction）

顾名思义根据缓存的容量回收，超过或即将超过最大容量的缓存将被回收，我们可以通过 CacheBuilder 来设置最大容量：

1CacheBuilder.newBuilder().maximumSize(100).build();

这个 size 指的是 cache 中的条目数，不是内存大小或是其他
并不是完全到了指定的 size 系统才开始移除不常用的数据的，而是接近这个 size 的时候系统就会开始做移除的动作
如果一个键值对已经从缓存中被移除了，你再次请求访问的时候，如果 cachebuild 是使用 cacheLoader 方式的，那依然还是会从 cacheloader 中再取一次值，如果这样还没有，就会抛出异常

根据源码注释可以看到，容量回收的算法是LRU（最近最少使用）

还可以根据缓存的“权重” 进行回收，什么意思呢？

每一项缓存所占据的内存空间大小都可能不一样，我们可以把它看作它们有不同的“权重”（weights）, 作为执行清除策略时优化回收的对象。不过感觉基于权重的用的比较少。下面是一个官方的例子：

 1LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder()
 2 .maximumWeight(100000)
 3 .weigher(new Weigher<Key, Graph>() {
 4 public int weigh(Key k, Graph g) {
 5 return g.vertices().size();
 6 }
 7 })
 8 .build(
 9 new CacheLoader<Key, Graph>() {
10 public Graph load(Key key) { // no checked exception
11 return createExpensiveGraph(key);
12 }
13 });

可以通过自定义一个 weight 函数来设置每项缓存的权重。

定时回收（Timed Eviction）

定时回收，或者说基于存活时间的回收，主要有两个参数：

expireAfterAccess 缓存项在给定时间内没有被读/写访问，则回收。这种缓存的回收顺序和基于大小回收一样。
expireAfterWrite 缓存项在给定时间内没有被写访问（创建或覆盖），则回收。如果认为缓存数据总是在固定时候后变得陈旧不可用，这种回收方式是可取的。

1CacheBuilder.newBuilder().expireAfterAccess(10, TimeUnit.SECONDS).expireAfterWrite(8,TimeUnit.SECONDS);

通过这两个参数的设置可以发现：定时回收周期性地在写操作中执行，偶尔在读操作中执行

我们在测试定时回收的时候不用设置了时间以后在那儿“傻等”，可以利用 Guava 的 Ticker 来模拟时间流逝，举个例子：

 1class FakeTicker extends Ticker {
 2
 3 private final AtomicLong nanos = new AtomicLong();
 4
 5 /** Advances the ticker value by {@code time} in {@code timeUnit}. */
 6 public FakeTicker advance(long time, TimeUnit timeUnit) {
 7 nanos.addAndGet(timeUnit.toNanos(time));
 8 return this;
 9 }
10
11 @Override
12 public long read() {
13 long value = nanos.getAndAdd(0);
14 System.out.println("is called " + value);
15 return value;
16 }
17}
18
19@Test
20public void expireAfterWriteTestWithTicker() throws InterruptedException {
21 FakeTicker t = new FakeTicker();
22
23 // Use ticker to force expire in 20 minute
24 LoadingCache<String, String> cache = CacheBuilder.newBuilder()
25 .expireAfterWrite(20, TimeUnit.MINUTES).ticker(t).build(ldr);
26 cache.getUnchecked("hello");
27 assertEquals(1, cache.size());
28 assertNotNull(cache.getIfPresent("hello"));
29
30 // add 21 minutes
31 t.advance(21, TimeUnit.MINUTES);
32 assertNull(cache.getIfPresent("hello")); 
33
34}

基于引用的回收（Reference-based Eviction）

Guava 允许你通过设置实现在 JVM GC 时回收缓存对象，这种移除方式主要是基于 java 的垃圾回收机制，根据键或者值的引用关系决定移除。

稍微复习一下 Java 的引用类型：

强引用：new 出来的一般对象，只要引用在就不会被回收
软引用：将要发生内存溢出之前回收
弱引用：生存到下一次垃圾收集发生之前
虚引用：目的是对象被收集器回收时收到一个系统通知

其中，软引用 soft reference 可用来实现内存敏感的高速缓存。而弱引用 weak reference 引用的对象是有价值被 cache, 而且很容易被重新构建，且很消耗内存的对象。所以软引用和弱引用被 Guava 利用来处理回收问题。

CacheBuilder.weakKeys() 使用弱引用存储键。当键没有其它（强或软）引用时，缓存项可以被垃圾回收。
CacheBuilder.weakValues()：使用弱引用存储值。当值没有其它（强或软）引用时，缓存项可以被垃圾回收。
CacheBuilder.softValues()：使用软引用存储值。软引用的对象会根据内存需求，以 LRU 的方式进行垃圾收集。

1Cache<String, String> cache = CacheBuilder.newBuilder().weakKeys().weakValues().softValues().build();

实际工作中用引用回收的很少。

上面我们介绍的回收方式，无论是基于容量回收、定时回收还是基于引用回收都是类似于自动回收的方式，下面我们介绍下手动显示回收，即手动回收缓存。

个别清除：Cache.invalidate(key)
批量清除：Cache.invalidateAll(keys)
清除所有缓存项：Cache.invalidateAll()

移除监听器

通过CacheBuilder.removalListener(RemovalListener)，你可以声明一个监听器，以便缓存项被移除时做一些额外操作。缓存项被移除时，RemovalListener会获取移除通知RemovalNotification，其中包含移除原因RemovalCause、键和值。

举个例子：

1 RemovalListener<String, String> myRemovalListener = notification -> {
2 System.out.println(notification.getCause().toString()+ " | [" + notification.getKey() + ":" + notification.getValue() + "] is removed!");
3
4 };
5 Cache<String, String> cache = CacheBuilder.newBuilder().removalListener(myRemovalListener).build();
6 cache.put("name","jack");
7 cache.put("id","123");
8 cache.invalidate("id");

输出：EXPLICIT | [id:123] is removed!

注意：默认情况下，监听器方法是在移除缓存时同步调用的。因为缓存的维护和请求响应通常是同时进行的，代价高昂的监听器方法在同步模式下会拖慢正常的缓存请求。在这种情况下，你可以使用RemovalListeners.asynchronous(RemovalListener, Executor)把监听器装饰为异步操作，比如：

1ExecutorService executor = Executors.newSingleThreadExecutor();
2Cache<Integer, Integer> cache1 = CacheBuilder.newBuilder().expireAfterWrite(2, TimeUnit.SECONDS)
3 .removalListener(RemovalListeners.asynchronous(notification -> {
4 System.out.println(notification.getCause());
5 System.out.println(notification.getKey() + " --> " + notification.getValue());
6 }, executor)).build();

缓存回收的时机

关于这点，只需要知道 Guava cache 缓存不会”自动”执行清理和回收工作，也不会在某个缓存项过期后马上清理，也没有诸如此类的清理机制。相反，它会在写操作时顺带做少量的维护工作，或者偶尔在读操作时做——如果写操作实在太少的话。

这样做的原因在于：如果要自动地持续清理缓存，就必须有一个线程，这个线程会和用户操作竞争共享锁。此外，某些环境下线程创建可能受限制，这样 CacheBuilder 就不可用了。

相反，Guava 把选择权交到我们手里。如果你的缓存是高吞吐的，那就无需担心缓存的维护和清理等工作。如果你的缓存只会偶尔有写操作，而你又不想清理工作阻碍了读操作，那么可以创建自己的维护线程，以固定的时间间隔调用Cache.cleanUp()

ScheduledExecutorService可以帮助你很好地实现这样的定时调度。

刷新

如果对缓存设置过期时间，在高并发下同时执行 get 操作，而此时缓存值已过期了，如果没有保护措施，则会导致大量线程同时调用生成缓存值的方法，比如从数据库读取，对数据库造成压力，这也就是我们常说的“缓存击穿”。

而 Guava cache 则对此种情况有一定控制。当大量线程用相同的 key 获取缓存值时，只会有一个线程进入 load 方法，而其他线程则等待（同步），直到缓存值被生成。这样也就避免了缓存击穿的危险。上述机制其实就是 expireAfterWrite/expireAfterAccess 来控制的，如果你配置了过期策略对应的缓存项在过期后被访问就会走上述流程来加载缓存项。

但这样做会导致大量的请求线程被阻塞。怎么办呢？

Guava cache 的办法是提供一种缓存策略，缓存值定时刷新 refreshAfterWrite ：更新线程调用 load 方法更新该缓存，其他请求线程返回该缓存的旧值。这样对于某个 key 的缓存来说，只会有一个线程被阻塞，用来生成缓存值，而其他的线程都返回旧的缓存值，不会被阻塞。

我们对比一下 refreshAfterWrite 和expireAfterWrite

expireAfterWrite 是允许一个线程进去 load 方法，其他线程阻塞等待。
refreshAfterWrite 是允许一个线程进去 load 方法，其他线程返回旧的值。

那么问题解决了吗？单个 key 并发下，使用 refreshAfterWrite，虽然不会阻塞了，但是如果恰巧多个 key 同时过期，还是会给数据库造成压力，这就是我们所说的“缓存雪崩”。这时就要用到异步刷新，将刷新缓存值的任务交给后台线程，所有的用户请求线程均返回旧的缓存值。方法是覆盖 CacheLoader 的reload方法，使用线程池去异步加载数据

“

只有重写了 reload 方法才有“异步加载”的效果。默认的 reload 方法就是同步去执行 load 方法

”

关于 reload 可以参考官方的例子：

 1//有些键不需要刷新，并且我们希望刷新是异步完成的
 2LoadingCache<Key, Graph> graphs = CacheBuilder.newBuilder()
 3 .maximumSize(1000)
 4 .refreshAfterWrite(1, TimeUnit.MINUTES)
 5 .build(
 6 new CacheLoader<Key, Graph>() {
 7 public Graph load(Key key) { // no checked exception
 8 return getGraphFromDatabase(key);
 9 }
10 
11 public ListenableFuture<Key, Graph> reload(final Key key, Graph prevGraph) {
12 if (neverNeedsRefresh(key)) {
13 return Futures.immediateFuture(prevGraph);
14 }else{
15 // asynchronous!
16 ListenableFutureTask<Key, Graph> task=ListenableFutureTask.create(new Callable<Key, Graph>() {
17 public Graph call() {
18 return getGraphFromDatabase(key);
19 }
20 });
21 executor.execute(task);
22 return task;
23 }
24 }
25 });

最佳实践：refreshTime < expireTime

因为，根据 get 的流程，在 get 的时候，是先判断过期，再判断 refresh（如果 refreshTime > expireTime 意味着永远走不到缓存刷新逻辑。)，即如果过期了会优先调用 load 方法（阻塞其他线程）。

在不过期情况下且过了 refresh 时间才去做 reload （异步加载，同时返回旧值），所以推荐的设置是 refresh < expire，这个设置还可以解决一个场景就是，如果长时间没有访问缓存，可以保证 expire 后可以取到最新的值，而不是因为 refresh 取到旧值。

可选配置

除了上文中已经介绍附带主题提到过的一些配置外，还有一些值得关注的配置：

缓存的并发级别

Guava 提供了设置并发级别的 api，使得缓存支持并发的写入和读取

1CacheBuilder.newBuilder()
2 // 设置并发级别为 cpu 核心数
3 .concurrencyLevel(Runtime.getRuntime().availableProcessors()) 
4 .build();

同 ConcurrentHashMap 类似 Guava cache 的并发也是通过分离锁实现。在一般情况下，将并发级别设置为服务器 cpu 核心数是一个比较不错的选择。

缓存的初始容量设置

我们在构建缓存时可以为缓存设置一个合理大小初始容量，由于 Guava 的缓存使用了分离锁的机制，扩容的代价非常昂贵。所以合理的初始容量能够减少缓存容器的扩容次数。

1CacheBuilder.newBuilder()
2 // 设置初始容量为 100
3 .initialCapacity(100)
4 .build();

统计信息

在构建 Cache 对象时，可以通过 CacheBuilder 的 recordStats 方法开启统计信息的开关。开关开启后 Cache 会自动对缓存的各种操作进行统计，调用 Cache 的 stats 方法可以查看统计后的信息。

CacheStats对象以提供如下统计信息：

hitRate()：缓存命中率；
averageLoadPenalty()：加载新值的平均时间，单位为纳秒；
evictionCount()：缓存项被回收的总数，不包括显式清除。

1 Cache<String, String> cache = CacheBuilder.newBuilder().recordStats().build();
2 cache.put("name", "jack");
3 cache.put("id", "123");
4 cache.invalidate("id");
5
6 System.out.println(cache.getIfPresent("name"));
7 System.out.println(cache.stats());

输出：

1jack
2CacheStats{hitCount=1, missCount=0, loadSuccessCount=0, loadExceptionCount=0, totalLoadTime=0, evictionCount=0}

asMap 视图

asMap 视图提供了缓存的 ConcurrentMap 形式，但 asMap 视图与缓存的交互需要注意：

cache.asMap() 包含当前所有加载到缓存的项。因此相应地，cache.asMap().keySet() 包含当前所有已加载键；
asMap().get(key) 实质上等同于 cache.getIfPresent(key)，而且不会引起缓存项的加载。这和 Map 的语义约定一致。
所有读写操作都会重置相关缓存项的访问时间，包括 Cache.asMap().get(Object) 方法和 Cache.asMap().put(K, V) 方法，但不包括 Cache.asMap().containsKey(Object) 方法，也不包括在 Cache.asMap() 的集合视图上的操作。比如，遍历 Cache.asMap().entrySet() 不会重置缓存项的读取时间。

Caffeine

从功能上看，Guava 已经比较完善了，满足了绝大部分本地缓存的需求。Caffine 除了提供 Guava 已有的功能外，同时还加入了一些扩展功能。

关于 Caffeine 的话题，限于篇幅，我们在以后的文章中再讨论。

总结

本文我们首先介绍了缓存的一些背景知识，了解了缓存的分类，以及内存缓存的一些开源库类，利用一些短小易懂的例子重点介绍了 Guava Cache，包括它的加载、更新、回收、配置、统计等功能。由于篇幅有限，有关常用的 JetCache 、Caffeine，还有一二级缓存的话题，有机会我会在后面的文章中跟大家再细聊。

参考

Redis 内存回收策略

Thu, 21 Apr 2022 08:22:02 +0000

Redis的内存回收机制主要体现在以下两个方面：

删除到达过期时间的键对象。
内存使用达到maxmemory上限时触发内存溢出控制策略。

过期删除策略

删除策略的目标：在内存占用与CPU占用之间寻找一种平衡，顾此失彼都会造成整体redis性能的下降，甚至引发服务器宕机或内存泄露。

设置Redis键过期时间

先回顾一下Redis 提供的设置过期时间的命令：

EXPIRE：表示将键 key 的生存时间设置为 ttl 秒。
PEXPIRE：表示将键 key 的生存时间设置为 ttl 毫秒。
EXPIREAT：表示将键 key 的生存时间设置为 timestamp 所指定的秒数时间戳。
PEXPIREAT：表示将键 key 的生存时间设置为 timestamp 所指定的毫秒数时间戳。

在Redis内部实现中，前面三个设置过期时间的命令最后都会转换成最后一个PEXPIREAT 命令来完成。

其他相关命令还有：

移除键的过期时间 PERSIST：表示将key的过期时间移除。
返回键的剩余生存时间
TTL：以秒的单位返回键 key 的剩余生存时间。
PTTL：以毫秒的单位返回键 key 的剩余生存时间。

在Redis内部，每当我们设置一个键的过期时间时，Redis就会将该键带上过期时间存放到一个过期字典中。当我们查询一个键时，Redis便首先检查该键是否存在过期字典中，如果存在，那就获取其过期时间。然后将过期时间和当前系统时间进行比对，比系统时间大，那就没有过期；反之判定该键过期。

此外：

对于字符串类型键，执行set命令会去掉过期时间，这个问题很容易在开发中被忽视
如下是Redis源码中，set命令的函数setKey，可以看到最后执行了removeExpire（db，key）函数去掉了过期时间：

 1void setKey(redisDb *db, robj *key, robj *val) {
 2 if (lookupKeyWrite(db,key) == NULL) {
 3 dbAdd(db,key,val);
 4 } else {
 5 dbOverwrite(db,key,val);
 6 }
 7 incrRefCount(val);
 8 // 去掉过期时间
 9 removeExpire(db,key);
10 signalModifiedKey(db,key);
11}

Redis不支持二级数据结构（例如哈希、列表）内部元素的过期功能，例如不能对列表类型的一个元素做过期时间设置。
setex命令作为set+expire的组合，不但是原子执行，同时减少了一次网络通讯的时间。

过期删除策略

通常删除某个key，我们有如下三种方式进行处理

1 定时删除

在设置某个key 的过期时间同时，我们创建一个定时器，让定时器在该过期时间到来时，立即执行对其进行删除的操作。

优点：定时删除对内存是最友好的，能够保存内存的key一旦过期就能立即从内存中删除。
缺点：对CPU最不友好，在过期键比较多的时候，删除过期键会占用一部分 CPU 时间，对服务器的响应时间和吞吐量造成影响。

2 惰性删除（Lazy delete）

设置该key 过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key。

优点：对 CPU友好，我们只会在使用该键时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查。
缺点：对内存不友好，如果一个键已经过期，但是一直没有使用，那么该键就会一直存在内存中，如果数据库中有很多这种使用不到的过期键，这些键便永远不会被删除，内存永远不会释放。从而造成内存泄漏。

3 定期删除

每隔一段时间，我们就对一些key进行检查，删除里面过期的key。

优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点：难以确定删除操作执行的时长和频率。
如果执行的太频繁，定期删除策略变得和定时删除策略一样，对CPU不友好。
如果执行的太少，那又和惰性删除一样了，过期键占用的内存不会及时得到释放。
另外最重要的是，在获取某个键时，如果某个键的过期时间已经到了，但是还没执行定期删除，那么就会返回这个键的值，这是业务不能忍受的错误

Redis 使用的过期删除策略

Redis所有的键都可以设置过期属性，内部保存在过期字典中。由于进程内保存大量的键，维护每个键精准的过期删除机制会导致消耗大量的CPU，对于单线程的Redis来说成本过高，因此Redis采用惰性删除和定时任务删除机制实现过期键的内存回收。

惰性删除：Redis的惰性删除策略由 db.c/expireIfNeeded 函数实现，所有键读写命令执行之前都会调用 expireIfNeeded 函数对其进行检查，如果过期，则删除该键，然后执行键不存在的操作；未过期则不作操作，继续执行原有的命令。

定期删除：由redis.c/activeExpireCycle 函数实现，函数以一定的频率运行，每次运行时，都从一定数量的数据库中取出一定数量的随机键进行检查，并删除其中的过期键。注意：并不是一次运行就检查所有的库，所有的键，而是随机检查一定数量的键。

定期删除函数的运行频率，在Redis2.6版本中，规定每秒运行10次，大概100ms运行一次。在Redis2.8版本后，可以通过修改配置文件redis.conf 的 hz 选项来调整这个次数。

看上面对这个参数的解释，建议不要将这个值设置超过 100，否则会对CPU造成比较大的压力。

定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例、使用快慢两种速率模式回收键，流程如下图所示：

内存淘汰策略（逐出算法）

当Redis所用内存达到maxmemory上限时会触发相应的溢出控制策略。

具体策略受maxmemory-policy参数控制，Redis支持8种策略（有关LFU算法的，是从Redis4.0以后版本才有）：

noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息（error）OOM command not allowed when used memory，此时Redis只响应读操作。生产一般不会选用
allkeys-lru 利用LRU算法移除任何key （不管数据有没有设置超时属性，直到腾出足够空间为止）。
allkeys-lfu 利用LRU算法移除任何key （不管数据有没有设置超时属性，直到腾出足够空间为止）
volatile-lru：根据LRU算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。
volatile-lfu:根据LFU算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。
allkeys-random 无差别的随机移除，直到腾出足够空间为止。
volatile-random：随机删除过期键，直到腾出足够空间为止。
volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略。

在redis.conf 配置文件中，可以设置淘汰方式：

内存溢出控制策略可以采用config set maxmemory-policy{policy}动态配置。Redis支持丰富的内存溢出应对策略，可以根据实际需求灵活定制，比如当设置volatile-lru策略时，保证具有过期属性的键可以根据LRU剔除，而未设置超时的键可以永久保留。还可以采用allkeys-lru策略把Redis变为纯缓存服务器使用。当Redis因为内存溢出删除键时，可以通过执行info stats命令查看evicted_keys指标找出当前Redis服务器已剔除的键数量。

LFU

LFU 算法（Least Frequently Used，最不经常使用）：淘汰最近一段时间被访问次数最少的数据，以次数作为参考。

需要指出的是：LRU 算法或者 TTL 算法都是不是很精确算法，而是一个近似的算法。Redis 不会通过对全部的键值对进行比较来确定最精确的时间值，从而确定删除哪个键值对，因为这将消耗太多的时间，导致回收垃圾执行的时间太长，造成服务停顿。

当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降，缓存污染情况比较严重。这时使用LFU可能更好点

LRU

LRU算法，最近最久未使用算法， Least Recently Used

下图是一个淘汰的流程：

在Redis中LRU算法是一个近似算法，默认情况下，Redis随机挑选5个键，并且从中选取一个最近最久未使用的key进行淘汰，在配置文件中可以通过maxmemory-samples的值来设置redis需要检查key的个数,但是检查的越多，耗费的时间也就越久,但是结构越精确(也就是Redis从内存中淘汰的对象未使用的时间也就越久~),设置多少，综合权衡吧~~~

Redis 3.0对这个近似算法的优化

新算法会维护一个候选池（大小为16），池中的数据根据访问时间进行排序，第一次随机选取的key都会放入池中，随后每次随机选取的key只有在访问时间小于池中最小的时间才会放入池中，直到候选池被放满。当放满后，如果有新的key需要放入，则将池中最后访问时间最大（最近被访问）的移除。当需要淘汰时，需要从池中捞出最久没被访问的key淘汰掉就行了。

新旧算法的对比

下面的图片是Redis官方文档给出的新旧算法对比结果：

浅灰色是被淘汰的数据
灰色是没有被淘汰掉的老数据
绿色是新加入的数据

可以看到3.0的效果明显比2.8的要得多，并且取样数越大，越接近标准的LRU算法

为什么Redis不使用真正的LRU ?

原因很简单，理论的LRU需要你占用更大的内存(每个key还需要保存前后key的地址), 但你从上图就可以看出Redis 3.0使用的近似LRU算法使用起来的效果几乎与理论的LRU等效了。

java实现LRU ？

Java自带的集合框架非常强大，实现LRU算法可以直接使用LinkedHashMap集合框架，简单实现的话，只需要重写 removeEldestEntry 方法即可。

 1import java.util.LinkedHashMap;
 2import java.util.Map.Entry;
 3
 4public class LRUCache extends LinkedHashMap {
 5 private static final long serialVersionUID = 1L;
 6 private final int capacity;
 7 private long accessCount = 0;
 8 private long hitCount = 0;
 9
10 public LRUCache(int capacity) {
11 super(capacity+1, 1.1f, true);
12 this.capacity = capacity;
13 }
14
15 public String get(String key) {
16 accessCount++;
17 if (super.containsKey(key)) {
18 hitCount++;
19 }
20 String value = (String)super.get(key);
21 return value;
22 }
23 
24 public boolean containsKey(String key) {
25 accessCount++;
26 if (super.containsKey(key)) {
27 hitCount++;
28 return true;
29 } else {
30 return false;
31 }
32 }
33
34 protected boolean removeEldestEntry(Entry eldest) {
35 return size() > capacity;
36 }
37
38 public long getAccessCount() {
39 return accessCount;
40 }
41
42 public long getHitCount() {
43 return hitCount;
44 }
45}

这是LinkedHashMap的一个构造函数，传入的第三个参数accessOrder为true的时候，就按访问顺序对LinkedHashMap排序，为false的时候就按插入顺序，默认是为false的。当把accessOrder设置为true后，就可以将最近访问的元素置于最前面。

1public LinkedHashMap(int initialCapacity,
2 float loadFactor,
3 boolean accessOrder) {
4 super(initialCapacity, loadFactor);
5 this.accessOrder = accessOrder;
6}

这是LinkedHashMap中另外一个方法，当返回true的时候，就会remove其中最久的元素，可以通过重写这个方法来控制缓存元素的删除，当缓存满了后，就可以通过返回true删除最久未被使用的元素，达到LRU的要求。

1protected boolean removeEldestEntry(Map.Entry<K,V> eldest) {
2 return false;
3}

参考

《Redis 开发与运维》
http://antirez.com/news/109
https://redis.io/docs/manual/eviction/
https://zhuanlan.zhihu.com/p/149528273
https://blog.51cto.com/u_15239532/2835914
https://www.geekxh.com/1.99.其他补充题目/11.htm
https://www.cnblogs.com/ysocean/p/12422635.html
https://blog.csdn.net/weixin_43230682/article/details/107670911

再聊聊Netty

Mon, 21 Mar 2022 07:13:56 +0000

为什么还要用 Netty

既然 JAVA NIO / JAVA AIO 已经实现了各主流操作系统的底层支持，那么为什么现在主流的 JAVA NIO 技术会是 Netty 和 MINA 呢？答案很简单：因为更好用，这里举几个方面的例子：

虽然 JAVA NIO 和 JAVA AIO 框架提供了多路复用 IO/异步 IO 的支持，但是并没有提供上层“信息格式”的良好封装。例如前两者并没有提供针对 Protocol Buffer、JSON 这些信息格式的封装，但是 Netty 框架提供了这些数据格式封装（基于责任链模式的编码和解码功能）
要编写一个可靠的、易维护的、高性能的（注意它们的排序） NIO/AIO 服务器应用。除了框架本身要兼容实现各类操作系统的实现外。更重要的是它应该还要处理

架构

整体架构

逻辑架构

线程模型

在高性能的 I/O 设计中，有两个著名的模型：Reactor 模型和 Proactor 模型，其中 Reactor 模型用于同步 I/O，而 Proactor 模型运用于异步 I/O 操作。实际上 Netty 线程模型就是 Reactor 模型的一个实现。

什么是 Reactor

“

The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.

”

Reactor 设计模式是一种事件处理模式，用于处理由一个或多个输入同时传递到服务处理程序的服务请求。然后，服务处理程序对传入的请求进行解复用，并将它们同步分派给关联的请求处理程序。

以上来自 wiki, 我们可以看到以下重点。

事件驱动（event handling）
可以处理一个或多个输入源（one or more inputs）
通过 Service Handler 同步的将输入事件（Event）采用多路复用分发给相应的 Request Handler（多个）处理

根据 Doug Lea 在《Scalable IO in Java 》中的介绍，Reacotr 模型主要分为三个角色：

Reactor：把 IO 事件分配给对应的 handler 处理
Acceptor：处理客户端连接事件
Handler：处理非阻塞的任务

Reactor 处理请求的流程：

同步的等待多个事件源到达（采用 select() 实现）
将事件多路分解以及分配相应的事件服务进行处理，这个分派采用 server 集中处理（dispatch）
分解的事件以及对应的事件服务应用从分派服务中分离出去（handler）

为什么使用 Reactor？

传统阻塞 IO 模型的不足

每个连接都需要独立线程处理，当并发数大时，创建线程数多，占用资源
采用阻塞 IO 模型，连接建立后，若当前线程没有数据可读，线程会阻塞在读操作上，造成资源浪费

针对传统阻塞 IO 模型的两个问题，可以采用如下的方案

基于池化思想，避免为每个连接创建线程，连接完成后将业务处理交给线程池处理
基于 IO 复用模型，多个连接共用同一个阻塞对象，不用等待所有的连接。遍历到有新数据可以处理时，操作系统会通知程序，线程跳出阻塞状态，进行业务逻辑处理

Reactor 线程模型分类

根据 Reactor 的数量和处理资源的线程数量的不同，分为三类：

单 Reactor 单线程模型
单 Reactor 多线程模型
多 Reactor 多线程模型

单 Reactor 单线程模型

消息处理流程：

Reactor 对象通过 select 监控连接事件，收到事件后通过 dispatch 进行转发。
如果是连接建立的事件，则由 acceptor 接受连接，并创建 handler 处理后续事件。
如果不是建立连接事件，则 Reactor 会分发调用 Handler 来响应。
handler 会完成 read->业务处理->send 的完整业务流程。

该线程模型的不足

仅用一个线程处理请求，对于多核资源机器来说是有点浪费的
当处理读写任务的线程负载过高后，处理速度下降，事件会堆积，严重的会超时，可能导致客户端重新发送请求，性能越来越差
单线程也会有可靠性的问题

Redis 是由 C 语言实现的，它采用的正是「单 Reactor 单进程」的方案，因为 Redis 业务处理主要是在内存中完成，操作的速度是很快的，性能瓶颈不在 CPU 上，所以 Redis 对于命令的处理是单进程的方案。

对于单线程的 Redis 来说，基于内存，且命令操作时间复杂度低，因此读写速率是非常快的。

针对上面的种种不足，就有了下面的线程模型

单 Reactor 多线程模型

消息处理流程：

Reactor 对象通过 Select 监控客户端请求事件，收到事件后通过 dispatch 进行分发。
如果是建立连接请求事件，则由 acceptor 通过 accept 处理连接请求，然后创建一个 Handler 对象处理连接完成后续的各种事件。
如果不是建立连接事件，则 Reactor 会分发调用连接对应的 Handler 来响应。
Handler 只负责响应事件，不做具体业务处理，通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理。
Worker 线程池会分配独立的线程完成真正的业务处理，然后将响应结果发给 Handler 进行处理。
Handler 收到响应结果后通过 send 将响应结果返回给 Client。

相对于第一种模型来说，在处理业务逻辑，也就是获取到 IO 的读写事件之后，交由线程池来处理，handler 收到响应后通过 send 将响应结果返回给客户端。这样可以降低 Reactor 的性能开销，从而更专注的做事件分发工作了，提升整个应用的吞吐。

但是这个模型存在的问题：

多线程数据共享和访问比较复杂。如果子线程完成业务处理后，把结果传递给主线程 Reactor 进行发送，就会涉及共享数据的互斥和保护机制。
Reactor 承担所有事件的监听和响应，只在主线程中运行，可能会存在性能问题。例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。

为了解决性能问题，产生了第三种主从 Reactor 多线程模型。

主从 Reactor 多线程模型

比起第二种模型，它是将 Reactor 分成两部分：

mainReactor 负责监听 server socket，用来处理网络 IO 连接建立操作，将建立的 socketChannel 指定注册给 subReactor。
subReactor 主要做和建立起来的 socket 做数据交互和事件业务处理操作。通常，subReactor 个数上可与 CPU 个数等同。

Nginx、Memcached 和 Netty 都是采用这种实现。

消息处理流程：

从主线程池中随机选择一个 Reactor 线程作为 acceptor 线程，用于绑定监听端口，接收客户端连接
acceptor 线程接收客户端连接请求之后创建新的 SocketChannel，将其注册到主线程池的其它 Reactor 线程上，由其负责接入认证、IP 黑白名单过滤、握手等操作
步骤 2 完成之后，业务层的链路正式建立，将 SocketChannel 从主线程池的 Reactor 线程的多路复用器上摘除，重新注册到 Sub 线程池的线程上，并创建一个 Handler 用于处理各种连接事件
当有新的事件发生时，SubReactor 会调用连接对应的 Handler 进行响应
Handler 通过 Read 读取数据后，会分发给后面的 Worker 线程池进行业务处理
Worker 线程池会分配独立的线程完成真正的业务处理，如何将响应结果发给 Handler 进行处理
Handler 收到响应结果后通过 Send 将响应结果返回给 Client

Reactor 三种模式形象比喻

餐厅一般有接待员和服务员，接待员负责在门口接待顾客，服务员负责全程服务顾客

Reactor 的三种线程模型可以用接待员和服务员类比

单 Reactor 单线程模型：接待员和服务员是同一个人，一直为顾客服务。客流量较少适合
单 Reactor 多线程模型：一个接待员，多个服务员。客流量大，一个人忙不过来，由专门的接待员在门口接待顾客，然后安排好桌子后，由一个服务员一直服务，一般每个服务员负责一片中的几张桌子
多 Reactor 多线程模型：多个接待员，多个服务员。这种就是客流量太大了，一个接待员忙不过来了

什么是 Proactor

Proactor 正是采用了异步 I/O 技术，所以被称为异步网络模型。

无论是 Reactor，还是 Proactor，都是一种基于「事件分发」的网络编程模式，区别在于 Reactor 模式是基于「待完成」的 I/O 事件，而 Proactor 模式则是基于「已完成」的 I/O 事件。

在 Linux 下的异步 I/O 是不完善的， aio 系列函数是由 POSIX 定义的异步操作接口，不是真正的操作系统级别支持的，而是在用户空间模拟出来的异步，并且仅仅支持基于本地文件的 aio 异步操作，网络编程中的 socket 是不支持的，这也使得基于 Linux 的高性能网络程序都是使用 Reactor 方案。

而 Windows 里实现了一套完整的支持 socket 的异步编程接口，这套接口就是 IOCP，是由操作系统级别实现的异步 I/O，真正意义上异步 I/O，因此在 Windows 里实现高性能网络程序可以使用效率更高的 Proactor 方案。

线程模型的应用

Redis

Redis 是典型的单 Reactor 单线程类型。Redis 主要通过 aeMain、aeProcessEvents，以及 aeCreateFileEvent 三个关键函数来实现 Reactor 模型，对源码 (Linux 系统）的整理如下：

源码文件	函数	被调用点	主要功能
ae.c/ae.h	aeMain()	server.c 的 main()	事件捕获，分发和循环处理
ae.c/ae.h	aeProcessEvents()	ae.c 的 aeMain()	根据事件类型进行响应的处理
ae.c/ae.h	aeApiPoll()	ae.c 的 aeProcessEvents()	调用操作系统的 IO 多路方法
Linux 内核文件	epoll_wait()	ae.c 的 aeApiPoll()	检测并返回内核中网络 IO 事件

nginx

nginx 是多进程模型，master 进程不处理网络 IO，每个 Wroker 进程是一个独立的单 Reacotr 单线程模型。详情参考官方文档：Inside NGINX: Designed for Performance & Scalability

Netty

Netty 的线程模型主要是基于 Reactor 模型，但是可以灵活配置，单 reactor 单线程，单 reactor 多线程，和多 reactor 多线程模型。

kafka

kafka 采用的是主从 Reactor 多线程模型，因为 Kafka 主要与磁盘 IO 交互，因此真正的读写数据不是从 Reactor 处理的，而是有一个 worker 线程池，专门处理磁盘 IO，从 Reactor 负责网络 IO，然后把任务交给 worker 线程池处理。

Netty 线程模型

上文说 Netty 就是采用 Reactor 模型实现的。下面是 Netty 使用中很常见的一段代码

 1public class Server {
 2 public static void main(String[] args) throws Exception {
 3 EventLoopGroup bossGroup = new NioEventLoopGroup(1);
 4 EventLoopGroup workerGroup = new NioEventLoopGroup();
 5 try {
 6 ServerBootstrap b = new ServerBootstrap();
 7 b.group(bossGroup, workerGroup)
 8 .channel(NioServerSocketChannel.class)
 9 .childOption(ChannelOption.TCP_NODELAY, true)
10 .childAttr(AttributeKey.newInstance("childAttr"), "childAttrValue")
11 .handler(new ServerHandler())
12 .childHandler(new ChannelInitializer<SocketChannel>() {
13 @Override
14 public void initChannel(SocketChannel ch) {
15 }
16 });
17 ChannelFuture f = b.bind(8888).sync();
18 f.channel().closeFuture().sync();
19 } finally {
20 bossGroup.shutdownGracefully();
21 workerGroup.shutdownGracefully();
22 }
23 }
24}

boss 线程池作用：

接收客户端的连接，初始化 Channel 参数。
将链路状态变更时间通知给 ChannelPipeline。

worker 线程池作用：

异步读取通信对端的数据报，发送读事件到 ChannelPipeline。
异步发送消息到通信对端，调用 ChannelPipeline 的消息发送接口。
执行系统调用 Task。
执行定时任务 Task。

通过配置 boss 和 worker 线程池的线程个数以及是否共享线程池等方式，Netty 的线程模型可以在以上三种 Reactor 模型之间进行切换。

netty 通过 Reactor 模型基于多路复用器接收并处理用户请求，内部实现了两个线程池，boss 线程池和 work 线程池：

其中 boss 线程池的线程负责处理请求的 accept 事件，当接收到 accept 事件的请求时，把对应的 socket 封装到一个 NioSocketChannel 中，并交给 worker 线程池
其中 worker 线程池负责请求的 read 和 write 事件

零拷贝

Netty 的接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外内存直接读写。

Netty 中的零拷贝和传统 Linux 的零拷贝不太一样。Netty 中的零拷贝技术除了操作系统级别的功能封装，更多的是面向用户态的数据操作优化，主要体现在以下 5 个方面：

堆外内存，避免 JVM 堆内存到堆外内存的数据拷贝。
CompositeByteBuf 类，可以组合多个 Buffer 对象合并成一个逻辑上的对象，避免通过传统内存拷贝的方式将几个 Buffer 合并成一个大的 Buffer。
通过 Unpooled.wrappedBuffer 可以将 byte 数组包装成 ByteBuf 对象，包装过程中不会产生内存拷贝。
ByteBuf.slice 操作与 Unpooled.wrappedBuffer 相反，slice 操作可以将一个 ByteBuf 对象切分成多个 ByteBuf 对象，切分过程中不会产生内存拷贝，底层共享一个 byte 数组的存储空间。
Netty 使用 FileRegion 实现文件传输，FileRegion 底层封装了 FileChannel#transferTo() 方法，可以将文件缓冲区的数据直接传输到目标 Channel，避免内核缓冲区和用户态缓冲区之间的数据拷贝，这属于操作系统级别的零拷贝。

堆外内存

如果在 JVM 内部执行 I/O 操作时，必须将数据拷贝到堆外内存，才能执行系统调用。这是所有 VM 语言都会存在的问题。那么为什么操作系统不能直接使用 JVM 堆内存进行 I/O 的读写呢？主要有两点原因：第一，操作系统并不感知 JVM 的堆内存，而且 JVM 的内存布局与操作系统所分配的是不一样的，操作系统并不会按照 JVM 的行为来读写数据。第二，同一个对象的内存地址随着 JVM GC 的执行可能会随时发生变化，例如 JVM GC 的过程中会通过压缩来减少内存碎片，这就涉及对象移动的问题了。

Netty 在进行 I/O 操作时都是使用的堆外内存，可以避免数据从 JVM 堆内存到堆外内存的拷贝。

NIO epoll bug

JDK 的 NIO 类库有一个 epoll 死循环 bug，它会导致 Selector 空轮询，IO 线程 CPU 达到 100%，严重影响系统运行。

netty 从 api 使用层面对该 bug 进行了规避解决，重建 Selector。当发生 epoll bug，则创建一个新的 Selector，将出现 bug 的 Selector 上的 channel 重新注册到新的 Selector 上，关闭 bug 的 Selector，使用新的 Selector 进行替换。

具体策略：

对 Selector 的 select 操作周期进行统计。
每完成一次空的 select 操作进行一次计数。
在某个周期内如果连续 N 次空轮询，则说明触发了 JDK NIO 的 epoll 死循环 bug。
创建新的 Selector，将出现 bug 的 Selector 上的 channel 重新注册到新的 Selector 上。
关闭 bug 的 Selector，使用新的 Selector 进行替换。

如果发生 epoll 死循环 bug，那么当前 I/O 线程将停下来进行 bug 的修复，然后再继续进行逻辑处理，bug 的修复是非阻塞操作，处理速度非常快；而且 netty 线程池中一般设置有多个 I/O 线程，其中某个 I/O 线程中的 Selector 触发 bug 并不会影响其他 I/O 线程运行，所以 netty 通过这种策略，在几乎不影响性能的情况下从 api 使用层面规避解决了该 bug。

粘包拆包

TCP 层可能会出现当次接收到的数据是不完整数据的情况。出现粘包可能的原因有：

发送方每次写入数据 < 套接字缓冲区大小；
接收方读取套接字缓冲区数据不够及时。

出现半包的可能原因有：

发送方每次写入数据 > 套接字缓冲区大小；
发送的数据大于协议 MTU，所以必须要拆包。

解决问题肯定不是在 4 层来做而是在应用层，通过定义通信协议来解决粘包和拆包的问题。发送方和接收方约定某个规则：

当发生粘包的时候通过某种约定来拆包；
如果在拆包，通过某种约定来将数据组成一个完整的包处理。

业界常用解决方案

定长协议

指定一个报文具有固定长度。比如约定一个报文的长度是 5 字节，那么：报文：1234，只有 4 字节，但是还差一个怎么办呢，不足部分用空格补齐。就变为：1234 。如果不补齐空格，那么就会读到下一个报文的字节来填充上一个报文直到补齐为止，这样粘包了。定长协议的优点是使用简单，缺点很明显：浪费带宽。

Netty 中提供了 FixedLengthFrameDecoder ，支持把固定的长度的字节数当做一个完整的消息进行解码。

特殊字符分割协议

很好理解，在每一个你认为是一个完整的包的尾部添加指定的特殊字符，比如：\n，\r 等等。需要注意的是：约定的特殊字符要保证唯一性，不能出现在报文的正文中，否则就将正文一分为二了。

Netty 中提供了 DelimiterBasedFrameDecoder 根据特殊字符进行解码，LineBasedFrameDecoder默认以换行符作为分隔符。

变长协议

变长协议的核心就是：将消息分为消息头和消息体，消息头中标识当前完整的消息体长度。

发送方在发送数据之前先获取数据的二进制字节大小，然后在消息体前面添加消息大小；
接收方在解析消息时先获取消息大小，之后必须读到该大小的字节数才认为是完整的消息。

Netty 中提供了 LengthFieldBasedFrameDecoder ，通过LengthFieldPrepender 来给实际的消息体添加 length 字段。

Netty 提供的能力

为了解决网络数据流的拆包粘包问题，Netty 为我们内置了如下的解码器：

ByteToMessageDecoder：如果想实现自己的半包解码器，实现该类；
MessageToMessageDecoder：一般作为二次解码器，当我们在 ByteToMessageDecoder 将一个 bytes 数组转换成一个 java 对象的时候，我们可能还需要将这个对象进行二次解码成其他对象，我们就可以继承这个类；
LineBasedFrameDecoder：通过在包尾添加回车换行符 \r\n 来区分整包消息；
StringDecoder：字符串解码器；
DelimiterBasedFrameDecoder：特殊字符作为分隔符来区分整包消息；
FixedLengthFrameDecoder：报文大小固定长度，不够空格补全；
ProtoBufVarint32FrameDecoder：通过 Protobuf 解码器来区分整包消息；
ProtobufDecoder：Protobuf 解码器；
LengthFieldBasedFrameDecoder：指定长度来标识整包消息，通过在包头指定整包长度来约定包长。

Netty 还内置了如下的编码器：

ProtobufEncoder：Protobuf 编码器；
MessageToByteEncoder：将 Java 对象编码成 ByteBuf；
MessageToMessageEncoder：如果不想将 Java 对象编码成 ByteBuf，而是自定义类就继承这个；
LengthFieldPrepender：LengthFieldPrepender 是一个非常实用的工具类，如果我们在发送消息的时候采用的是：消息长度字段+原始消息的形式，那么我们就可以使用 LengthFieldPrepender。这是因为 LengthFieldPrepender 可以将待发送消息的长度（二进制字节长度）写到 ByteBuf 的前两个字节。

UDP 是否会发生粘包或拆包的现象呢？

答案是不会。

UDP 是基于报文发送的，从 UDP 的帧结构可以看出，在 UDP 首部采用了 16bit 来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

而TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段，基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。

API

ByteBuf

ByteBuf 是一个字节容器，内部是一个字节数组。从逻辑上来分，字节容器内部，可以分为四个部分：

第一个部分是已经丢弃的字节，这部分数据是无效的；
第二部分是可读字节，这部分数据是 ByteBuf 的主体数据，从 ByteBuf 里面读取的数据都来自这一部分；
第三部分的数据是可写字节，所有写到 ByteBuf 的数据都会写到这一段。
第四部分的字节，表示的是该 ByteBuf 最多还能扩容的大小。

四个部分的逻辑功能，如下图所示：

ByteBuf 通过三个整型的指针（index），有效地区分可读数据和可写数据，使得读写之间相互没有冲突。

这三个指针，分别是：

readerIndex（读指针）
writerIndex（写指针）
maxCapacity（最大容量）

这三个指针，是三个 int 型的成员属性，定义在 AbstractByteBuf 抽象基类中。三个指针的代码截图，如下：

readerIndex 读指针

指示读取的起始位置。

每读取一个字节，readerIndex 自增 1 。一旦 readerIndex 与 writerIndex 相等，ByteBuf 不可读。

writerIndex 写指针

指示写入的起始位置。

每写一个字节，writerIndex 自增 1。一旦增加到 writerIndex 与 capacity（）容量相等，表示 ByteBuf 已经不可写了。

“

capacity（）容量不是一个成员属性，是一个成员方法。表示 ByteBuf 内部的总容量。注意，这个不是最大容量。

”

maxCapacity 最大容量

指示可以 ByteBuf 扩容的最大容量。

当向 ByteBuf 写数据的时候，如果容量不足，可以进行扩容。

扩容的最大限度，直到 capacity（）扩容到 maxCapacity 为止，超过 maxCapacity 就会报错。

“

capacity() 扩容的操作，是底层自动进行的。

”

从三个维度三大系列，介绍 ByteBuf 的常用 API 方法。

第一组：容量系列

方法一：capacity()

表示 ByteBuf 的容量，包括丢弃的字节数、可读字节数、可写字节数。
方法二：maxCapacity()

表示 ByteBuf 底层最大能够占用的最大字节数。当向 ByteBuf 中写数据的时候，如果发现容量不足，则进行扩容，直到扩容到 maxCapacity。

第二组：写入系列

方法一：isWritable()

表示 ByteBuf 是否可写。如果 capacity（）容量大于 writerIndex 指针的位置，则表示可写。否则为不可写。

isWritable() 的源码，也是很简单的。具体如下：
```
1public boolean isWritable() {
2
3 return this.capacity() > this.writerIndex;
4
5} 
```

“

注意：如果 isWritable() 返回 false，并不代表不能往 ByteBuf 中写数据了。如果 Netty 发现往 ByteBuf 中写数据写不进去的话，会自动扩容 ByteBuf。

”

方法二：writableBytes()

返回表示 ByteBuf 当前可写入的字节数，它的值等于 capacity（）- writerIndex。

如下图所示：
方法三：maxWritableBytes()

返回可写的最大字节数，它的值等于 maxCapacity-writerIndex 。
方法四：writeBytes(byte[] src)

把字节数组 src 里面的数据全部写到 ByteBuf。

这个是最为常用的一个方法。
方法五：writeTYPE(TYPE value）基础类型写入方法

基础数据类型的写入，包含了 8 大基础类型的写入。

具体如下：writeByte()、 writeBoolean()、writeChar()、writeShort()、writeInt()、writeLong()、writeFloat()、writeDouble() ，向 ByteBuf 写入基础类型的数据。
方法六：setType(TYPE value）基础类型写入，不改变指针值

基础数据类型的写入，包含了 8 大基础类型的写入。

具体如下：setByte()、 setBoolean()、setChar()、setShort()、setInt()、setLong()、setFloat()、setDouble() ，向 ByteBuf 写入基础类型的数据。

“

setType 系列与 writeType 系列的不同：

”

setType 系列不会改变写指针 writerIndex ；

writeTYPE 系列会改变写指针 writerIndex 的值。
方法七：markWriterIndex() 与 resetWriterIndex()

这里两个方法一起介绍。

前一个方法，表示把当前的写指针 writerIndex 保存在 markedWriterIndex 属性中后一个方法，表示把当前的写指针 writerIndex 恢复到之前保存的 markedWriterIndex 值。

标记 markedWriterIndex 属性，定义在 AbstractByteBuf 抽象基类中。

截图如下：

第三组：读取系列

方法一：isReadable()

表示 ByteBuf 是否可读。如果 writerIndex 指针的值大于 readerIndex 指针的值，则表示可读。否则为不可写。

isReadable() 的源码，也是很简单的。具体如下：
```
1public boolean isReadable() {
2
3 return this.writerIndex > this.readerIndex;
4
5} 
```
方法二：readableBytes()

返回表示 ByteBuf 当前可读取的字节数，它的值等于 writerIndex - readerIndex 。

如下图所示：
方法三：readBytes(byte[] dst)

把 ByteBuf 里面的数据全部读取到 dst 字节数组中，这里 dst 字节数组的大小通常等于 readableBytes() 。这个方法，也是最为常用的一个方法。
方法四：readType(）基础类型读取

基础数据类型的读取，可以读取 8 大基础类型。

具体如下：readByte()、readBoolean()、readChar()、readShort()、readInt()、readLong()、readFloat()、readDouble() ，从 ByteBuf 读取对应的基础类型的数据。
方法五：getTYPE(TYPE value）基础类型读取，不改变指针值

基础数据类型的读取，可以读取 8 大基础类型。

具体如下：getByte()、 getBoolean()、getChar()、getShort()、getInt()、getLong()、getFloat()、getDouble() ，从 ByteBuf 读取对应的基础类型的数据。

“

getType 系列与 readTYPE 系列的不同：

”

getType 系列不会改变读指针 readerIndex ；

readTYPE 系列会改变读指针 readerIndex 的值。
方法六：markReaderIndex() 与 resetReaderIndex()

前一个方法，表示把当前的读指针 ReaderIndex 保存在 markedReaderIndex 属性中。

后一个方法，表示把当前的读指针 ReaderIndex 恢复到之前保存的 markedReaderIndex 值。

标记 markedReaderIndex 属性，定义在 AbstractByteBuf 抽象基类中。

截图如下：

pipeline

ChannelPipeline 和 ChannelHandler 机制类似于 servlet 和 Filter 过滤器，这类拦截器实际上是职责链模式的一种变形，主要为了方便事件的拦截和用户业务逻辑的定制。
ChannelPipeline 实际上是一个 ChannelHandler 的容器，内部维护了一个 ChnnelHandler 的链表和迭代器，可以方便地实现 ChannelHandler 查找、添加、替换和删除。

参考

Redis 分布式解决方案

Tue, 25 Jan 2022 10:12:53 +0000

概述

在 Redis 3.0 之前，集群方案一般为两种：

客户端分区方案
代理方案

3.0 之后官方提供了专有的集群方案 Redis Cluster。

将数据集分散到多个节点上，每个节点负责整体的一部分，即为数据分区。分区就会涉及到分区规则，Redis 常用的是哈希分区规则，哈希分区规则比较常见的有

节点取余分区
一致性 hash 算法
虚拟槽分区

客户端分区

也叫客户端分片（Smart Client）如下图所示，为一个客户端分区方案。

通过 sentinel 实现集群高可用，分区逻辑在客户端实现

优点是：分区逻辑可控。缺点是：需要自己处理数据路由、高可用、故障转移等问题。

分区规则可用节点取余 hash

节点取余 hash

节点取余方式优点：

配置简单：对数据进行哈希，然后取余

节点取余方式缺点：

数据节点伸缩时，导致数据迁移
迁移数量和添加节点数据有关，建议翻倍扩容

代理方案

代理分区方案一般由中间件实现例如早已开源的 Codis，下图是 Codis 的架构图：

codis-proxy 是无状态的，可以比较容易的搭多个实例，达到高可用性和横向扩展。

对 Java 用户来说，可以使用基于 Jedis 的实现 Jodis ，来实现 proxy 层的 HA：

它会通过监控 zookeeper 上的注册信息来实时获得当前可用的 proxy 列表，既可以保证高可用性；
也可以通过轮流请求所有的 proxy 实现负载均衡。

这种方案有很多优点，因为支持原生 redis 协议，所以客户端不需要升级，对业务比较友好。并且升级相对平滑，可以起多个 Proxy 后，逐个进行升级。

“

Codis 是一个分布式 Redis 解决方案，对于上层的应用来说，连接到 Codis Proxy 和连接原生的 Redis Server 没有显著区别（不支持的命令列表）, 上层应用可以像使用单机的 Redis 一样使用，Codis 底层会处理请求的转发，不停机的数据迁移等工作，所有后边的一切事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的 Redis 服务。

”

但是缺点是，因为会多一次跳转，会有性能开销。

这里我们再讨论另外一种分区规则：一致性 hash 算法

一致性 hash 算法

上面讨论的节点取余分区方式的主要缺点是：数据节点伸缩时，导致数据迁移，换句话说，当缓存服务器数量发生变化时，可能会导致大量缓存同一时间失效，几乎所有缓存的位置都会发生改变。所以 迁移数量和添加节点数据有关，建议翻倍扩容

一致性 hash 算法在一定程度上解决了这个问题，它的实现思路是：为系统中每个节点分配一个 token, 范围是 0 到 2 的 32 次方，这些 token 构成一个哈希环，如下图所示。

每一个数据节点分配一个 token 范围值，这个节点就负责保存这个范围内的数据。数据读写执行节点查找操作时，先根据 key 计算 hash 值，然后顺时针找到第一个大于等于该哈希值的 token 节点（沿顺时针方向遇到的第一个服务器）。

优点：服务器的数量如果发生改变，并不是所有缓存都会失效，而是只有部分缓存会失效

缺点：

加减节点会造成哈希环中部分数据无法命中，需要手动处理或者忽略这分部数据。
当使用少量节点时，节点变化将大范围影响哈希环中数据映射，不适合少量数据节点的分布式方案。
普通的一致性哈希分区在增减节点时需要增加一倍或减去一半节点才能保证数据和负载的均衡。

上述缺点中第二、三点尤其重要，原因是缓存分布的极度不均匀（负载不均衡），这种情况被称之为 hash 环的偏斜

应该怎样防止 hash 环的偏斜呢？一致性 hash 算法中使用“虚拟节点”解决了这个问题。

“虚拟节点”是”实际节点”（实际的物理服务器）在 hash 环上的复制品，一个实际节点可以对应多个虚拟节点。

例如：我们以 2 个副本 NodeA、NodeB 为例，为每台服务器计算三个虚拟节点，于是可以分别计算 “Node A#1”、“Node A#2”、“Node A#3”、“Node B#1”、“Node B#2”、“Node B#3”的哈希值，于是形成六个虚拟节点：

当然，如果你需要，也可以虚拟出更多的虚拟节点。引入虚拟节点的概念后，缓存的分布就均衡多了。hash 环上的节点就越多，缓存被均匀分布的概率就越大。

Redis Cluster

在简介 Redis Cluster 之前，先聊一聊它采用的分区规则，即虚拟槽分区

虚拟槽分区

Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，计算公式 slot = CRC16(key) & 16383，每个节点负责维护一部分槽以及槽所映射的键值数据。采用大范围槽的主要目的是为了方便数据拆分和集群扩展

当前集群有 5 个节点，每个节点平均大约负责 3276 个槽。由于采用高质量的哈希算法，每个槽所映射的数据通常比较均匀，将数据平均划分到 5 个节点进行数据分区。

虚拟槽分区特点：

解耦数据和节点之间的关系，简化了节点扩容和收缩难度
节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据。
可以对数据打散，又可以保证数据分布均匀

Redis Cluster

Redis Cluster 集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
自动将数据进行分片，每个 master 上放一部分数据
提供内置的高可用支持，部分 master 不可用时，还是可以继续工作的

集群由 N 组主从 Redis Instance 组成。主可以没有从，但是没有从意味着主宕机后主负责的 Slot 读写服务不可用。一个主可以有多个从，主宕机时，某个从会被提升为主，具体哪个从被提升为主，协议类似于 Raft。

如何检测主宕机？

Redis Cluster 采用 quorum+心跳的机制。从节点的角度看，节点会定期给其他所有的节点发送 Ping，cluster-node-timeout（可配置，秒级）时间内没有收到对方的回复，则单方面认为对端节点宕机，将该节点标为 PFAIL 状态。通过节点之间交换信息收集到 quorum 个节点都认为这个节点为 PFAIL，则将该节点标记为 FAIL，并且将其发送给其他所有节点，其他所有节点收到后立即认为该节点宕机。从这里可以看出，主宕机后，至少 cluster-node-timeout 时间内该主所负责的 Slot 的读写服务不可用。

与 Sentinal 的区别？

Redis Sentinal 着眼于高可用，在 master 宕机时会自动将 slave 提升为 master，继续提供服务。
Redis Cluster 着眼于扩展性，在单个 redis 内存不足时，使用 Cluster 进行分片存储。

参考

幂等解决方案集合（二）消息幂等

Tue, 16 Nov 2021 09:57:23 +0000

问题描述

消息队列的消息幂等性，主要是由 MQ 重试机制引起的。

我们通常会认为，消息中间件是一个可靠的组件——这里所谓的可靠是指，只要我把消息成功投递到了消息中间件，消息就不会丢失，即消息肯定会至少保证消息能被消费者成功消费一次，这是消息中间件最基本的特性之一，也就是我们常说的“AT LEAST ONCE”，即消息至少会被“成功消费一遍”。

举个例子，一个消息 M 发送到了消息中间件，消息投递到了消费程序 A，A 接受到了消息，然后进行消费，但在消费到一半的时候程序重启了，这时候这个消息并没有标记为消费成功，这个消息还会继续投递给这个消费者，直到其消费成功了，消息中间件才会停止投递。然而这种可靠的特性导致，消息可能被多次地投递。

再举个例子，程序 A 接受到这个消息 M 并完成消费逻辑之后，正想通知消息中间件“我已经消费成功了”的时候，程序就重启了，那么对于消息中间件来说，这个消息并没有成功消费过，所以他还会继续投递。这时候对于应用程序 A 来说，看起来就是这个消息明明消费成功了，但是消息中间件还在重复投递。

解决方案

基于业务表的去重

假如我们的逻辑是这样的：

1
2select * from t_order where order_no = 'order123'
3
4if(order != null) {
5
6 return ;//消息重复，直接返回
7
8}

那么在并下情况下可能会有问题（当业务还没处理完，此时并发的请求进来了，则会穿透掉检查的挡板），所以要考虑原子性问题。

解决的办法在我们上一篇文章中也有介绍到，即使用：

悲观锁（SELECT ... FOR UPDATE）
乐观锁

但无论是 select for update，还是乐观锁这种解决方案，实际上都是基于业务表本身做去重，这无疑增加了业务开发的复杂度，如果每个消费逻辑本身都需要基于业务本身而做去重/幂等的开发的话，这是繁琐的工作量。

基于消息表+本地事务

我们以 RocketMQ 作为消息中间件为例， RocketMQ 的文档中描述道：

“

RocketMQ 无法避免消息重复（Exactly-Once），所以如果业务对消费重复非常敏感，务必要在业务层面进行去重处理。可以借助关系数据库进行去重。首先需要确定消息的唯一键，可以是 msgId，也可以是消息内容中的唯一标识字段，例如订单 Id 等。在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。（实际过程要考虑原子性问题，判断是否存在可以尝试插入，如果报主键冲突，则插入失败，直接跳过）

”

“

msgId 一定是全局唯一标识符，但是实际使用中，可能会存在相同的消息有两个不同 msgId 的情况（消费者主动重发、因客户端重投机制导致的重复等），这种情况就需要使业务字段进行重复消费。

”

根据文档的描述我们得到了第一种解决方案，即通过去重表的方法，这点在上一篇文章《幂等解决方案集合（一）》中已有所描述，需要注意的是：

“

在消费之前判断唯一键是否在关系数据库中存在。如果不存在则插入，并消费，否则跳过。

”

具体来说，我们可以这样做：在数据库中增加一个消息消费记录表，把业务操作和这个消息插入的动作放到同一个事务中一起提交，就能保证消息只会被消费一遍了。

开启事务
插入消息表（处理好主键冲突的问题）
更新订单表（原消费逻辑）
提交事务

但是这里有它的局限性

消息的消费逻辑必须是依赖于关系型数据库事务。如果消费的消费过程中还涉及其他数据的修改，例如 Redis 这种不支持事务特性的数据源，则这些数据是不可回滚的。
数据库的数据必须是在一个库，跨库无法解决

使用 Exactly-Once 投递语义收发消息

Exactly-Once 投递语义

以下引用自阿里云的文档：

“

Exactly-Once是指发送到消息系统的消息只能被消费端处理且仅处理一次，即使生产端重试消息发送导致某消息重复投递，该消息在消费端也只被消费一次。

”

“

Exactly-Once语义是消息系统和流式计算系统中消息流转的最理想状态，但是在业界并没有太多理想的实现。因为真正意义上的 Exactly-Once 依赖消息系统的服务端、消息系统的客户端和用户消费逻辑这三者状态的协调。例如，当您的消费端完成一条消息的消费处理后出现异常宕机，而消费端重启后由于消费的位点没有同步到消息系统的服务端，该消息有可能被重复消费。

”

“

业界对于Exactly-Once投递语义存在很大的争议，很多人会拿出“FLP 不可能理论”或者其他一致性定律对此议题进行否定，但事实上，特定场景的 Exactly-Once 语义实现并不是非常复杂，只是因为通常大家没有精确的描述问题的本质。

”

“

如果您要实现一条消息的消费结果只能在业务系统中生效一次，您需要解决的只是如何保证同一条消息的消费幂等问题。消息队列RocketMQ版的Exactly-Once语义就是解决业务中最常见的一条消息的消费结果（消息在消费端计算处理的结果）在数据库系统中有且仅生效一次的问题。

”

典型使用场景

“

在电商系统中，上游实时计算模块发布商品价格变更的信息，异步通知到下游商品管理模块进行价格变更。此时，需要保证每一条信息的消费幂等，即重复的价格变更信息只会生效一次，这样便不会发生价格多次重复修改的情况，确保实现了消息消费的幂等。

”

操作步骤

1 添加依赖

消息队列 RocketMQ 版的 ExactlyOnceConsumer 在客户端 SDK ons-client-ext-1.8.4.Final 中发布，若要使用 Exactly-Once 投递语义，需在应用中依赖该 SDK。另外，ExactlyOnceConsumer 基于 Spring 实现了通过注解@MQTransaction 开启 Exactly-Once 消费的方式，因此还需要在应用中增加 Spring 3.0 以上版本的依赖。

完整的依赖内容如下所示。

 1<dependency>
 2 <groupId>com.aliyun.openservices</groupId>
 3 <artifactId>ons-client-ext</artifactId>
 4 <version>1.8.4.Final</version>
 5</dependency>
 6<dependency>
 7 <groupId>org.springframework</groupId>
 8 <artifactId>spring-context</artifactId>
 9 <version>${spring-version}</version>
10</dependency>
11<dependency>
12 <groupId>org.springframework</groupId>
13 <artifactId>spring-jdbc</artifactId>
14 <version>${spring-version}</version>
15</dependency>

2 在用于存储消息消费结果的数据库中创建 transaction_record 表 (注意：存储消息消费结果的数据库系统必须支持本地事务)

若要使用消息队列 RocketMQ 版的 Exactly-Once 投递语义，您需要在业务处理结果持久化的数据库中创建一张 transaction_record 表，保证此表与存储业务处理结果的表在同一个数据库内，且该数据库支持本地事务。目前，消息队列 RocketMQ 版的 Exactly-Once 投递语义支持您的业务访问 MySQL 和 SQLServer 两种类型的数据源。这两种类型的数据源下 transaction_record 表的建表语句如以下所示 (mysql)。

 1CREATE TABLE `transaction_record` (
 2 `consumer_group` varchar(128) NOT NULL DEFAULT '',
 3 `message_id` varchar(255) NOT NULL DEFAULT '',
 4 `topic_name` varchar(255) NOT NULL DEFAULT '',
 5 `ctime` bigint(20) NOT NULL,
 6 `queue_id` int(11) NOT NULL,
 7 `offset` bigint(20) NOT NULL,
 8 `broker_name` varchar(255) NOT NULL DEFAULT '',
 9 `id` bigint(20) NOT NULL AUTO_INCREMENT,
10 PRIMARY KEY (`id`),
11 UNIQUE KEY `message_id_unique_key` (`message_id`),
12 KEY `ctime_key` (`ctime`),
13 KEY `load_key` (`queue_id`,`broker_name`,`topic_name`,`ctime`)
14) ENGINE=InnoDB DEFAULT CHARSET=utf8;

3 在消息生产端使用 PropertyKeyConst.EXACTLYONCE_DELIVERY 属性设置打开 Exactly-Once 投递语义

 1/**
 2 * TestExactlyOnceProducer 启动
 3 * 通过 PropertyKeyConst.EXACTLYONCE_DELIVERY 开启 exactly-once 投递语义。
 4 */
 5
 6public class TestExactlyOnceProducer {
 7 public static void main(String[] args) {
 8 Properties producerProperties = new Properties();
 9 producerProperties.setProperty(PropertyKeyConst.GROUP_ID,"{GROUP_ID}");
10 producerProperties.setProperty(PropertyKeyConst.AccessKey,"{accessKey}");
11 producerProperties.setProperty(PropertyKeyConst.SecretKey,"{secretKey}");
12 producerProperties.setProperty(PropertyKeyConst.NAMESRV_ADDR,"{NAMESRV_ADDR}");
13 producerProperties.setProperty(PropertyKeyConst.EXACTLYONCE_DELIVERY,"true");
14 Producer producer = ExactlyOnceONSFactory.createProducer(producerProperties);
15 producer.start();
16 System.out.println("Producer Started");
17
18 for (int i = 0; i < 10; i++) {
19 Message message = new Message("{topic}", "{tag}", "mq send transaction message test".getBytes());
20 try {
21 SendResult sendResult = producer.send(message);
22 assert sendResult != null;
23 System.out.println(new Date() + " Send mq message success! msgId is: " + sendResult.getMessageId());
24 } catch (ONSClientException e) {
25 System.out.println("发送失败");
26 //出现异常意味着发送失败，为避免消息丢失，建议缓存该消息然后进行重试。
27 }
28 }
29 producer.shutdown();
30 }
31}

4 在消息消费端创建 ExactlyOnceConsumer，并开启 Exactly-Once 的消费模式。

使用消息队列 RocketMQ 版的 Exactly-Once 投递语义进行消费时，消费端需要使用 ExactlyOnceONSFactory 调用 createExactlyOnceConsumer 接口创建 ExactlyOnceConsumer，然后通过使用 ExactlyOnceConsumer 进行 Exactly-Once 模式的消费。

在使用 ExactlyOnceConsumer 时，需要注意以下两点：

创建 ExactlyOnceConsumer 时，可以通过设置 PropertyKeyConst.EXACTLYONCE_DELIVERY 属性打开或者关闭 Exactly-Once 投递语义。ExactlyOnceConsumer 默认打开 Exactly-Once 投递语义。
使用 ExactlyOnceConsumer 消费时，在消息监听器 MessageListener 的 consume 方法中，您的业务处理逻辑需要使用 MQDataSource 对数据库的进行读写操作。

您可以选择以下任一方式在消费端开启 Exactly-Once 投递语义：

以非 Spring 方式开启 Exactly-Once 投递语义
MessageListener 中以事务方式实现多项数据库操作和消息消费的事务性
MessageListener 中通过 Springboot 注解方式实现开启 Exactly-Once 投递语义
MessageListener 中通过 MyBatis 方式实现 Exactly-Once 投递语义

以下示例为：MessageListener 中以事务方式实现多项数据库操作和消息消费的事务性，其他示例代码，请参考阿里云文档：https://help.aliyun.com/document_detail/102777.html

 1/**
 2 * TestExactlyOnceListener 实现。
 3 * 实现了一个事务中对多个业务表进行更新的场景，保证事务内的操作有且仅有一次生效。
 4 */
 5public class SimpleTxListener implements MessageListener {
 6 private MQDataSource dataSource;
 7
 8 public SimpleTxListener() {
 9 this.dataSource = new MQDataSource("{url}", "{user}", "{passwd}", "{driver}");
10 }
11
12 @Override
13 public Action consume(Message message, ConsumeContext context) {
14 Connection connection = null;
15 Statement statement = null;
16 try {
17 /**
18 * 在此处对消费到的消息 message 做业务计算处理，使用 MQDataSource 将处理结果持久化到数据库系统。
19 * 此范例演示了在一个事务内对多个表进行更新的业务场景，Exactly-Once 投递语义保证事务内的操作有且仅有一次。
20 * 实际的业务处理按照：接收消息->业务处理->结果持久化的流程来设计。
21 */
22 connection = dataSource.getConnection();
23 connection.setAutoCommit(false);
24 String insertSql = String.format("INSERT INTO app(msg, message_id, ctime) VALUES(\"%s\", \"%s\", %d)",
25 new String(message.getBody()), message.getMsgID(), System.currentTimeMillis());
26 String updateSql = String.format("UPDATE consume_count SET cnt = count + 1 WHERE consumer_group = \"%s\"", "GID_TEST");
27 statement = connection.createStatement();
28 statement.execute(insertSql);
29 statement.execute(updateSql);
30 connection.commit();
31 System.out.println("consume message :" + message.getMsgID());
32 return Action.CommitMessage;
33 } catch (Throwable e) {
34 try {
35 connection.rollback();
36 } catch (Exception e1) {
37 }
38 System.out.println("consume message fail");
39 return Action.ReconsumeLater;
40 } finally {
41 if (statement != null) {
42 try {
43 statement.close();
44 } catch (Exception e) { }
45 }
46 if (connection != null) {
47 try {
48 connection.close();
49 } catch (Exception e) { }
50 }
51 }
52 } 
53}

总结

你可以看到，这种方式是阿里云做了封装，但理论上跟上一个方案基于消息表+本地事务是一样的。

利用 Redis

最后这种方案其实思路跟基于消息表+本地事务类似，只不过判断是否重复消息用 Redis 分布式锁实现，关于具体实现步骤也跟我们上一篇文章类似，请参考上一篇文章。

最后

当消费者出现异常，可以让其重试几次，如果重试几次后，仍然有异常，则需要进行数据补偿。数据补偿方案：当重试多次后仍然出现异常，则让此条消息进入 死信队列，最终进入到数据库中，接着设置定时 job 查询这些数据，进行手动补偿。

参考

https://github.com/apache/rocketmq/blob/master/docs/cn/best_practice.md
https://www.baiyp.ren/%E4%B8%9A%E5%8A%A1%E5%B9%82%E7%AD%89%E6%80%A7%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1.html
https://mp.weixin.qq.com/s/Ojdh0-POjucg_De8OdQfwQ
https://help.aliyun.com/document_detail/102777.html

幂等解决方案集合（一）

Fri, 12 Nov 2021 10:22:55 +0000

什么是幂等（idempotent）

百度百科：

“

幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。

”

“

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。

”

“

这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“setTrue()”函数就是一个幂等函数，无论多次执行，其结果都是一样的。更复杂的操作幂等保证是利用唯一交易号（流水号）实现。

”

幂等的数学概念

幂等是源于一种数学概念。其主要有两个定义

如果在一元运算中，x 为某集合中的任意数，如果满足，那么该 f 运算具有幂等性，比如绝对值运算就是幂等性函数。

如果在二元运算中，x 为某集合中的任意数，如果满足，前提是 f 运算的两个参数均为 x，那么我们称 f 运算也有幂等性，比如求大值函数就是幂等性函数。

幂等的业务概念

幂等性不仅仅只是一次或多次操作对资源没有产生影响，还包括第一次操作产生影响后，以后多次操作不会再产生影响。并且幂等关注的是是否对资源产生影响，而不关注结果。

举例：服务端会进行重试等操作或客户端有可能会进行多次点击提交。如果这样请求多次的话，那最终处理的数据结果就一定要保证统一，如支付场景。此时就需要通过保证业务幂等性方案来完成。

幂等的维度

时间
空间

时域唯一性

定义幂等的有效期。有些业务需要永久性保证幂等，如下单、支付等。而部分业务只要保证一段时间幂等即可。你希望在多长时间内保证某次操作的幂等？

空域唯一性

定义了幂等的范围，如生成订单的话，不允许出现重复下单。一次操作=服务方法+传入的业务数据

同时对于幂等的使用一般都会伴随着出现锁的概念，用于解决并发安全问题。

HTTP 协议语义幂等性

引用自：

“

安全方法对于 GET 和 HEAD 方法而言，除了进行获取资源信息外，这些请求不应当再有其他意义。也就是说，这些方法应当被认为是“安全的”。客户端可能会使用其他“非安全”方法，例如 POST，PUT 及 DELETE，应该以特殊的方式（通常是按钮而不是超链接）告知客户可能的后果（例如一个按钮控制的资金交易），或请求的操作可能是不安全的（例如某个文件将被上传或删除）。但是，不能想当然地认为服务器在处理某个 GET 请求时不会产生任何副作用。事实上，很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。副作用假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作“幂等 (idempotence)”的。GET，HEAD，PUT 和 DELETE 方法都有这样的幂等属性，同样由于根据协议，OPTIONS，TRACE 都不应有副作用，因此也理所当然也是幂等的。假如一个由若干请求组成的请求序列产生的结果，在重复执行这个请求序列或者其中任何一个或多个请求后仍没有发生变化，则这个请求序列便是“幂等”的。但是，可能出现一个由若干请求组成的请求序列是“非幂等”的，即使这个请求序列中所有执行的请求方法都是幂等的。例如，这个请求序列的结果依赖于某个会在下次执行这个序列的过程中被修改的变量。

”

总结下：

HTTP Method	Idempotent	Safe
OPTIONS	yes	yes
GET	yes	yes
HEAD	yes	yes
PUT	yes	no
POST	no	no
DELETE	yes	no
PATCH	no	no

常见幂等问题

业务上

当用户购物进行下单操作，用户操作多次，但订单系统对于本次操作只能产生一个订单（不控制会导致恶意刷单）。
当用户对订单进行付款，支付系统不管出现什么问题，应该只对用户扣一次款。
当支付成功对库存扣减时，库存系统对订单中商品的库存数量也只能扣减一次。
当对商品进行发货时，也需保证物流系统有且只能发一次货。

技术上

前端重复提交表单，导致同一条数据重复提交。
当添加重试机制，一个请求重试多次，导致数据不一致。
当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

前端解决方案

前端防重

通过前端防重保证幂等是最简单的实现方式，前端相关属性和 JS 代码即可完成设置。可靠性并不好，有经验的人员可以通过工具跳过页面仍能重复提交。主要适用于表单重复提交或按钮重复点击。

PRG 模式

PRG 模式即 POST-REDIRECT-GET。当用户进行表单提交时，会重定向到另外一个提交成功页面，而不是停留在原先的表单页面。这样就避免了用户刷新导致重复提交。同时防止了通过浏览器按钮前进/后退导致表单重复提交。是一种比较常见的前端防重策略。

Token 模式

token 模式主要是为了防重的。

需要前后端进行一定程度的交互来完成。需要利用到 Redis。

具体流程步骤：

客户端会先发送一个请求去获取 token，服务端会生成一个全局唯一的 ID 作为 token 保存在 redis 中，同时把这个 ID 返回给客户端
客户端第二次调用业务请求的时候必须携带这个 token
服务端会校验这个 token，如果校验成功，则执行业务，并删除 redis 中的 token
如果校验失败，说明 redis 中已经没有对应的 token，则表示重复操作，直接返回指定的结果给客户端

注意：

在并发情况下，执行 Redis 查找数据与删除需要保证原子性，否则很可能在并发下无法保证幂等性。其实现方法可以使用分布式锁或者使用 Lua 表达式来注销查询与删除操作。
全局唯一 ID 可以用百度的 uid-generator、美团的 Leaf 去生成

Redis 分布式锁可以利用：典型的实现 setnx + getset 或 Redisson

这里给出两种实现的核心方法，首先是用 Redisson 的：

 1/**
 2 * 创建 Token 存入 Redis，并返回该 Token
 3 * @param value 用于辅助验证的 value 值
 4 * @return 生成的 Token 串
 5 */
 6 public String generateToken(String value) {
 7 
 8 String token = UUID.randomUUID().toString();
 9 String key = IDEMPOTENT_TOKEN_PREFIX + token;
10 /**
11 * 在真实业务中 采用唯一标志 例如 流水号啊
12 */
13 redisTemplate.opsForValue().set(key, value, 5, TimeUnit.MINUTES);
14 return token;
15 }
16
17 /**
18 * 分布式锁实现幂等性
19 */
20 @PostMapping("/distributeLock")
21 @ApiOperation(value = "分布式锁实现幂等性")
22 public String distributeLock(HttpServletRequest request) {
23 
24 String token = request.getHeader("token");
25 // 获取用户信息（这里使用模拟数据）
26 String userInfo = "mydlq";
27 RLock lock = redissonClient.getLock(token);
28 lock.lock(10, TimeUnit.SECONDS);
29 try {
30 
31 Boolean flag = tokenUtilService.validToken2(token, userInfo);
32 // 根据验证结果响应不同信息
33 if (flag) {
34 
35 /**
36 * 执行正常的逻辑
37 */
38 log.info("执行正常的逻辑………………");
39 }
40 return flag ? "正常调用" : "重复调用";
41 } catch (Exception e) {
42 
43 e.printStackTrace();
44 return "重复调用";
45 } finally {
46 
47 lock.unlock();
48 }
49 }

然后是带 Lua 脚本的

 1 /**
 2 * 验证 Token 正确性
 3 *
 4 * @param token token 字符串
 5 * @param value value 存储在 Redis 中的辅助验证信息
 6 * @return 验证结果
 7 */
 8 public Boolean validToken(String token, String value) {
 9 
10 // 设置 Lua 脚本，其中 KEYS[1] 是 key，KEYS[2] 是 value, 这段 lua 脚本的意思是获取 redis 的 KEYS[1] 的值，与 KEYS[2] 的值作比较，如果相等则返回 KEYS[1] 的值并删除 redis 中的 KEYS[1], 否则返回 0
11 String script = "if redis.call('get',KEYS[1]) == KEYS[2] then return redis.call('del', KEYS[1]) else return 0 end";
12 RedisScript<Long> redisScript = new DefaultRedisScript<>(script, Long.class);
13 // 根据 Key 前缀拼接 Key
14 String key = IDEMPOTENT_TOKEN_PREFIX + token;
15 // 执行 Lua 脚本
16 Long result = redisTemplate.execute(redisScript, Arrays.asList(key, value));
17 // 根据返回结果判断是否成功匹配并删除 Redis 键值对，若果结果不为空和 0，则验证通过
18 if (result != null && result != 0L) {
19 
20 log.info("验证 token={},key={},value={} 成功", token, key, value);
21 return true;
22 }
23 log.info("验证 token={},key={},value={} 失败", token, key, value);
24
25 return false;
26 }

Lua 脚本的比较好理解，这里说两句 Redisson 的，Redisson 的锁在调用redissonClient.getLock(“myLockKey”) 时，redis 中不能存在同名的 key, 不然会报错。redisson 锁其内部是基于 lua 脚本语言完成锁获取的。因为获取锁的过程涉及到了多步，为了保证执行过程的原子性，使用了 Lua 脚本。

具体就是这段：

1<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
2 return this.evalWriteAsync(this.getRawName(), LongCodec.INSTANCE, command, "if (redis.call('exists', KEYS[1]) == 0) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return nil; end; return redis.call('pttl', KEYS[1]);", Collections.singletonList(this.getRawName()), new Object[]{unit.toMillis(leaseTime), this.getLockName(threadId)});
3 }

关于 Redisson 锁还有几个进阶的概念比如：“红锁”，感兴趣的朋友可以看一下：http://redis.cn/topics/distlock.html

后端解决方案

利用数据库实现的方案

去重表

去重表的实现思路也非常简单，首先创建一张表作为去重表，同时在该表中建立一个或多个字段的唯一索引作为防重字段，用于保证并发情况下，数据只有一条。在向业务表中插入数据之前先向去重表插入，如果插入失败则表示是重复数据。

比如：同一个用户同一件商品不能在同一分钟下两次单，那么就需要 user_id, product_id, created_at 这三个字段做为去重字段。

唯一主键 insert、delete 场景

可以通过设置数据库的唯一主键约束或唯一索引约束来实现，这样重复的 key 就不会插入成功了。比如你用 userId 为 1 的数据插入，第一次成功了再重试一次就不会成功了。

这个方案可以防止新增脏数据，具有防重效果。

防重设计 和 幂等设计，是有区别的。防重设计主要为了避免产生重复数据，对接口返回没有太多要求。而幂等设计除了避免产生重复数据之外，还要求每次请求都返回一样的结果

乐观锁 update 场景

数据库乐观锁方案一般只能适用于执行更新操作的过程，我们可以提前在对应的数据表中多添加一个字段，充当当前数据的版本标识。

基本思路是：版本号+条件，实现思想是基于 MySQL 的行锁思想来实现的。以订单扣减库存举例：

如果我们只以版本号作为条件更新

1update tb_stock set amount=amount-#{num},version=version+1 where goods_id=#{goodsId} and version=#{version}

那么同时下单的用户就只有一个能扣减库存成功，其他的都失败。这种情况我们可以再加入一个条件来判断比如：

1update tb_stock set amount=amount-#{num} where goods_id=#{goodsId} and amount-#{num}>=0

只要不发生超卖就可以了。

举一反三，也可以用在订单只支付一次的场景，只不过条件不同罢了（也有称这种方法为状态标识或状态机幂等），比如：

1update table item set item.status=:newstatus where item.id = :id and item.status = oldstatus

当然这也仅仅是保证了接口的幂等性，放在真实的分布式环境里，服务间的调用很可能会涉及分布式事务，那么还需要在幂等的基础上加分布式事务的解决方案，比如 seata, 有关分布式事务由于不属于本文的重点就不多讨论了。但幂等是一个很重要基础，它能够保证业务数据的一致性。

为什么不用悲观锁？

首先悲观锁有可能会锁表，有性能问题。

比如 select for update

“

由于 InnoDB 预设是 Row-Level Lock，所以只有「明确」的指定主键，MySQL 才会执行 Row lock （行锁），否则 MySQL 将会执行 Table Locck（锁表）Lock

”

其次使用悲观锁有可能产生死锁

比如：一个用户 A 访问表 A（锁住了表 A），然后试图访问表 B；另一个用户 B 访问表 B（锁住了表 B），然后试图访问表 A。这时对于用户 A 来说，由于表 B 已经被用户 B 锁住了，所以用户 A 必须等到用户 B 释放表 B 才能访问。同时对于用户 B 来说，由于表 A 已经被用户 A 锁住了，所以用户 B 必须等到用户 A 释放表 A 才能访问。此时死锁就已经产生了。

redis 分布式锁实现

具体流程步骤：

客户端先请求服务端，会拿到一个能代表这次请求业务的唯一字段
将该字段以 SETNX 的方式存入 redis 中，并根据业务设置相应的超时时间
如果设置成功，证明这是第一次请求，则执行后续的业务逻辑
如果设置失败，则代表已经执行过当前请求，直接返回

整体来看，与上文的 token 方案中使用 redis 类似，基本还是分布式 ID+分布式锁。

比较适合于服务间调用时的接口幂等，比如订单调库存，订单调用支付等。

比如订单先生成了一个 id 标识（比如订单号），id 标识可由分布式 ID 生成器生成，然后带着这个标识一起请求库存，如果之前没有在 redis 存过则正常执行，如果发生接口重试，再次用相同 id 标识请求，redis 返回失败表示重复请求。

这里比较重要的是要记得设置 redis 的过期时间，具体时间要根据

业务执行时间
上游系统或整个系统整体的重试次数以及时间设置

假设我们设置为 2 秒，那么套一下业务就是：比如同一个订单（id 标识是订单号），在 2 秒内执行了 2 次以上扣减库存，很明显是一个重复操作，需要幂等处理（返回失败表示重复请求）。

如果不考虑重试次数和时间，一旦 redis key 超时失效，调用方服务再次重试还是无法保证幂等。

消息幂等

在接收消息的时候，消息推送重复。如果处理消息的接口无法保证幂等，那么重复消费消息产生的影响可能会非常大。

具体解决方案请看下回分解。

Redis on 小盒子的技术分享

数据库选型终极指南：从数据类型到应用场景，一篇就够了

引言

数据库的分类

关系型数据库（RDBMS）：结构化数据的基石

NoSQL 数据库：灵活性与扩展性的革命

大数据生态数据库：分布式与批量处理的支柱

总结

数据类型

结构化数据：秩序与约束的领域

半结构化数据：灵活性与动态性的平衡

非结构化数据：海量与多元化的挑战

总结

应用场景

关系型:MySQL

搜索引擎：ES

文档型：MongoDB

键值存储：Redis

宽列存储：HBase、Cassandra

数据仓库：Hive

列式存储：ClickHouse

图数据库：Neo4j

总结

最后总结

Redis6.0 以后为什么使用了多线程？

6.0 之前为什么要使用单线程

6.0 之后的多线程主要解决什么问题

局限性

Milvus实战：如何用一个数据库提升你的AI项目性能

回顾

本地文件存储

向量数据库

向量数据库选型

Chroma

Milvus

总结

关于 Redis 的有趣的知识

关于 Redis 的有趣的知识

跟着 Guava 学 Java 之缓存

背景

什么是缓存

缓存的特点

解决什么问题

内存缓存库类

Guava 缓存

加载

缓存回收

移除监听器

缓存回收的时机

刷新

可选配置

统计信息

asMap 视图

Caffeine

总结

参考

Redis 内存回收策略

过期删除策略

设置Redis键过期时间

过期删除策略

Redis 使用的过期删除策略

内存淘汰策略 （逐出算法）

LFU

LRU

参考

再聊聊Netty

为什么还要用 Netty

架构

线程模型

什么是 Reactor

单 Reactor 单线程模型

单 Reactor 多线程模型

主从 Reactor 多线程模型

什么是 Proactor

线程模型的应用

Netty 线程模型

零拷贝

NIO epoll bug

粘包拆包

业界常用解决方案

内存淘汰策略（逐出算法）