goMars的学习随记

领域驱动设计（DDD）概述DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。 按照 DDD 方法设计出的微服务的业务和应用边界都非常合理，可以很好地实现微服务内部和外部的“高内聚、低耦合”。 为什么 DDD 适合微服务？ DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。 相关名词 领域和子域： 在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。 DDD 的领域就是这个边界内要解决的业务问题域，而子域就是领域再细分，对应一个更小的问题域或更小的业务范围。 每一个细分的领域都会有一个知识体系，也就是 DDD 的领域模型。 核心域、通用域和支撑域： 子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。 核心域：决定产品和公司核心竞争力的子域是核心域，它是 ...

Redis6.0新特性从单线程处理网络请求到多线程处理在之前Redis 一直被大家熟知的就是它的单线程架构，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF 重写），但是，从网络 IO 处理到实际的读写命令处理，都是由单个线程完成的。 但是后来硬件的发展，单个主线程处理网络请求的速度跟不上底层网络硬件的速度。 Redis6.0为了解决这个问题，采用了多个 IO 线程来处理网络请求，提高网络请求处理的并行度的方案。但是，Redis 的多 IO 线程只是用来处理网络请求的，对于读写命令，Redis 仍然使用单线程来处理。 具体多个IO线程的使用是在解析请求以及写会响应的阶段（利用并行提高速度）： 相关设置： 开启多线程：io-threads-do-reads yes 设置多线程数量：io-threads 6（一般来说，线程个数要小于 Redis 实例所在机器的 CPU 核个数，例如，对于一个 8 核的机器来说，Redis 官方建议配置 6 个 IO 线程。） 实现服务端协助的客户端缓存和之前的版本相比，Redis 6.0 新增了一个重要的特性，就是实 ...

数据倾斜数据倾斜有两类。 数据量倾斜：在某些情况下，实例上的数据分布不均衡，某个实例上的数据特别多。 数据访问倾斜：虽然每个集群实例上的数据量相差不大，但是某个实例上的数据是热点数据，被访问得非常频繁。 数据量倾斜 bigkey 导致倾斜 bigkey 的 value 值很大（String 类型），或者是 bigkey 保存了大量集合元素（集合类型），会导致这个实例的数据量增加，内存资源消耗也相应增加。 解决方法： 我们在业务层生成数据时，要尽量避免把过多的数据保存在同一个键值对中。 如果 bigkey 正好是集合类型，我们还有一个方法，就是把 bigkey 拆分成很多个小的集合类型数据，分散保存在不同的实例上。 Slot 分配不均衡导致倾斜 如果没有均衡地分配 Slot，就会有大量的数据被分配到同一个 Slot 中，而同一个 Slot 只会在一个实例上分布，这就会导致，大量数据被集中到一个实例上，造成数据倾斜。 解决方法： 在分配之前，我们就要避免把过多的 Slot 分配到同一个实例。 如果已经分配，可以对不合理的slot进行迁移 Hash Tag导致倾斜 Hash ...

秒杀场景秒杀场景的负载特征对支撑系统的要求 特征是瞬时并发访问量非常高。 一般数据库每秒只能支撑千级别的并发请求，而 Redis 的并发处理能力（每秒处理请求数）能达到万级别，甚至更高。所以，当有大量并发请求涌入秒杀系统时，我们就需要使用 Redis 先拦截大部分请求，避免大量请求直接发送给数据库，把数据库压垮。 特征是读多写少，而且读操作是简单的查询操作。 库存查验操作是典型的键值对查询，而 Redis 对键值对查询的高效支持，正好和这个操作的要求相匹配。 秒杀的三个阶段 秒杀活动前 在这个阶段，用户会不断刷新商品详情页，这会导致详情页的瞬时请求量剧增。这个阶段的应对方案，一般是尽量把商品详情页的页面元素静态化，然后使用 CDN 或是浏览器把这些静态化的元素缓存起来。 秒杀活动开始 这个阶段的操作就是三个：库存查验、库存扣减和订单处理。（并发主要是在库存查验操作上） 库存查验： 为了支撑大量高并发的库存查验请求，我们需要在这个环节使用 Redis 保存库存量，这样一来，请求可以直接从 Redis 中读取库存并进行查验。 库存扣减： 需要使用Redis来执行； 因为放在数据 ...

主从问题 数据不一致主要原因： 主从库间的网络可能会有传输延迟，所以从库不能及时地收到主库发送的命令，从库上执行同步命令的时间就会被延后。 另一方面，即使从库及时收到了主库的命令，但是，也可能会因为正在处理其它复杂度高的命令（例如集合操作命令）而阻塞。此时，从库需要处理完当前的命令，才能执行主库发送的命令操作，这就会造成主从数据不一致。 两种方法： 在硬件环境配置方面，我们要尽量保证主从库间的网络连接状况良好。 我们还可以开发一个外部程序来监控主从库间的复制进度。 因为 Redis 的 INFO replication 命令可以查看主库接收写命令的进度信息（master_repl_offset）和从库复制写命令的进度信息（slave_repl_offset），所以，我们就可以开发一个监控程序，先用 INFO replication 命令查到主、从库的进度，然后，我们用 master_repl_offset 减去 slave_repl_offset，这样就能得到从库和主库间的复制进度差值了。 如果某个从库的进度差值大于我们预设的阈值，我们可以让客户端不再和这个从库连接进行数据读取 ...

主从同步同步流程当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步。 第一阶段：是主从库间建立连接、协商同步的过程，主要是为全量复制做准备。（从库给主库发送 psync 命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。） 在第二阶段：主库将所有数据同步给从库。从库收到数据后，在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。（从库接收到 RDB 文件后，会先清空当前数据库，然后加载 RDB 文件） 第三个阶段：主库会把第二阶段执行过程中新收到的写命令，再发送给从库。 存在问题问题一： 一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于 fork 子进程生成 RDB 文件，进行数据全量同步，导致fork操作阻塞主线程。 解决：通 ...

Redis事务Redis 提供了 MULTI、EXEC 两个命令来进行事务操作。 MULTI：表示一个事务的开启，之后客户端发过来的命令都会暂存到一个命令队列中，并不会立即执行。 EXEC：当服务器端收到 EXEC 命令后，才会实际执行命令队列中的所有命令。 Redis 的事务机制能保证哪些属性？原子性 没有发生错误：那操作可以保证原子性 执行发生错误：需要分3种情况 在执行 EXEC 命令前，客户端发送的操作命令本身就有错误。（例如语法错误等） 此时，我们还能继续提交命令操作。等到执行了 EXEC 命令之后，Redis 就会拒绝执行所有提交的命令操作。 在执行 EXEC 命令前，命令和操作的数据类型不匹配，但 Redis 实例没有检查出错误。 Redis会对错误命令报错，但还是会把正确的命令执行完。在这种情况下，事务的原子性就无法得到保证了。 如果有错误语句可以使用DISCAR命令来让事务放弃 在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。 如果 Redis 开启了 AOF 日志，使用 redis-check-aof 工具检查 AOF ...

应对高并发我们在使用 Redis 时，不可避免地会遇到并发访问的问题。 为了保证并发访问的正确性，Redis 提供了两种方法，分别是加锁和原子操作。 加锁加锁是一种常用的方法，在读取数据前，客户端需要先获得锁，否则就无法进行操作。当一个客户端获得锁后，就会一直持有这把锁，直到客户端完成数据更新，才释放这把锁。 缺点： 如果加锁操作多，会降低系统的并发访问性能。 Redis 客户端要加锁时，需要用到分布式锁，而分布式锁实现复杂，需要用额外的存储系统来提供加解锁操作。 分布式锁 基于单个 Redis 节点实现分布式锁 用Redis存锁变量，key为变量名，value为锁的值；例如：lock_key:0 为了保证锁操作的原子性，需要使用原子操作的语句来实现加锁与释放锁。 加锁：SET key value [EX seconds | PX milliseconds] [NX]例如：SET lock_key unique_value NX PX 10000其中，unique_value 是客户端的唯一标识，可以用一个随机生成的字符串来表示，PX 10000 则表示 lock_key 会在 ...

缓存与数据库一致性问题概述这里的“一致性”包含了两种情况： 缓存中有数据，那么，缓存的数据值需要和数据库中的值相同； 缓存中本身没有数据，那么，数据库中的值必须是最新值。 不符合这两种情况的，就属于缓存和数据库的数据不一致问题了。 解决方案重试机制具体来说，可以把要删除的缓存值或者是要更新的数据库值暂存到消息队列中（例如使用 Kafka 消息队列）。当应用没有能够成功地删除缓存值或者是更新数据库值时，可以从消息队列中重新读取这些值，然后再次进行删除或更新。 两种不同顺序存在的问题： 情况一：先删除缓存，再更新数据库。 延迟双删方案：在线程 A 更新完数据库值以后，我们可以让它先 sleep 一小段时间，再进行一次缓存删除操作。 情况二：先更新数据库值，再删除缓存值。 这种情况对业务的影响较小。 总结：

内存替换策略策略分类Redis 4.0 之前一共实现了 6 种内存淘汰策略，在 4.0 之后，又增加了 2 种策略。 我们可以按照是否会进行数据淘汰把它们分成两类： 不进行数据淘汰的策略，只有 noeviction 这一种。 会进行淘汰的 7 种其他策略。 在设置了过期时间的数据中进行淘汰，包括 volatile-random、volatile-ttl、volatile-lru、volatile-lfu（Redis 4.0 后新增）四种。 在所有数据范围内进行淘汰，包括 allkeys-lru、allkeys-random、allkeys-lfu（Redis 4.0 后新增）三种。 策略详讲 noeviction 策略 Redis 在使用的内存空间超过 maxmemory 值时，并不会淘汰数据，也就是设定的 noeviction 策略。 对应到 Redis 缓存，也就是指，一旦缓存被写满了，再有写请求来时，Redis 不再提供服务，而是直接返回错误。 基于过期时间的四种策略 volatile-ttl：在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除， ...