技术总结(二十五)
一、订单号是否唯一?如何保证唯一性?
唯一
订单号必须是唯一的。订单号的唯一性是确保订单系统正常运行的基础，可以避免订单冲突和数据处理错误。
保证订单号唯一性的方法
-
UUID（Universally Unique Identifier）：UUID是一种通用唯一识别码，由32个16进制数字组成，形式为8-4-4-12的36个字符。UUID在理论上保证了全球范围内的唯一性，但其缺点是生成的ID是无序的，每次插入都会对主键底层的b+树进行较大的修改1。
-
雪花算法（Snowflake）：这是Twitter开发的一种全局唯一ID生成服务，生成的ID是一个64位的整数，可以有序生成，每秒能够产生约400万个自增可排序的ID。雪花算法在高并发情况下表现良好，适用于分布式系统1。
-
数据库自增：在数据库中设置自增列，通过查询当前最大的订单号并加1来生成新的订单号。这种方法简单易用，但在高并发情况下可能会出现问题，且对数据的分表处理不够友好1。
-
全局数据库：使用一个全局数据库，所有生成订单的API会首先访问这个数据库的订单表获得订单号，这样可以保证子库订单号不重复1。
-
分布式组件：例如使用Redis作为分布式组件，通过Redis的队列、incr等功能来实现订单号的生成和分配1。
二、Redis是单线程还是多线程
Redis在核心操作上是单线程的，但整体实现上并非完全单线程。以下是对Redis线程模型的详细解释：
一、核心操作的单线程性
Redis在处理客户端请求、键值对读写等核心操作时，使用单个线程（主线程）来完成。这种设计有助于降低锁竞争和线程切换的开销，使得Redis在处理大量并发请求时具有较高的性能。此外，Redis通过使用非阻塞的I/O多路复用机制来实现高效的网络通信，进一步提升了性能。
二、其他功能的多线程性
虽然Redis在核心操作上是单线程的，但其整体实现上并非完全单线程。例如，Redis在持久化、异步删除、集群数据同步等功能上，会由额外的线程来执行。这些线程通常被称为后台线程（BIO），它们负责处理一些耗时较长或不影响Redis主线程性能的任务。
具体来说，Redis在2.6版本及之后，会启动后台线程来处理关闭文件、AOF刷盘等任务。在4.0版本之后，Redis还新增了一个后台线程，用来异步释放Redis内存，即lazyfree线程。这些后台线程的存在，使得Redis能够在保持高性能的同时，处理一些复杂的任务。
三、Redis集群方案应该怎么做？都有那些方法
-
Redis Cluster（官方集群方案）
- 数据分片原理
- Redis Cluster 采用哈希槽（Hash Slot）的方式来进行数据分片。整个集群共有 16384 个哈希槽，数据的键（Key）通过 CRC16 算法计算出一个 16 位的值，然后对 16384 取模，从而确定该键对应的哈希槽。例如，一个电商系统中的商品库存信息存储在 Redis 中，每个商品的库存键（如 “product_stock_1”）经过哈希计算后会被分配到一个特定的哈希槽中。不同的节点负责不同范围的哈希槽，这样就实现了数据在集群中的分布。
- 节点间通信与故障转移
- 节点通信：Redis Cluster 中的节点之间会通过一种叫做 Gossip 协议的方式进行通信。每个节点会定期地向其他节点发送消息，这些消息包含了节点自身的状态、哈希槽的分配情况等信息。通过这种方式，节点可以获取到整个集群的状态。例如，当新节点加入或者节点出现故障时，其他节点可以通过 Gossip 协议及时了解到这些情况。
- 故障转移：当一个主节点出现故障时，它的从节点会通过选举机制成为新的主节点。选举过程基于 Raft 协议的变种，从节点之间会相互通信，比较各自的复制偏移量等信息来确定谁可以成为新的主节点。例如，在一个高可用的 Redis Cluster 存储用户会话信息的场景中，如果一个主节点发生故障，其对应的从节点可以快速接管服务，确保用户会话数据的可用性。
- 配置与部署要点
- 节点数量与哈希槽分配：在部署 Redis Cluster 时，需要合理规划节点数量和哈希槽的分配。一般建议至少有 3 个主节点，每个主节点可以有一个或多个从节点。在分配哈希槽时，要确保每个哈希槽都有对应的负责节点，并且尽量均匀地分配哈希槽，以避免数据倾斜。
- 网络设置：由于节点之间需要频繁通信，因此要确保集群内的网络稳定和低延迟。同时，需要对节点的 bind 地址和端口等网络参数进行正确配置，使得节点之间能够正常连接。
- 数据分片原理