技术和基础设施→ Redis：记忆解决方桉

Redis： 内存解决方桉

1） Redis在哪里

• Kesh（read-through/aside，TTL，SWR）和会议。
• 计数器和配额：限额限制，反限额，竞选限额。
• 领导板/排名（ZSet），"top N"建议。
• 活动队列/总线（Streams/PubSub）、outbox/inbox、retrai。
• 相等性（带有TTL的键），de-dup webhook。
• Geo（查找最近的点），Bitmap（标志，DAU）。
• 别名/令牌和短寿命授权缓存。

2）数据结构及其应用时间

字符串：值/计数器（"INCRBY"），等效键。
Hash：配置文件/组合,存储"轻量级"对象。
List：简单的队列（但没有replay/offset语义）。
集合：独特的元素，重复数据消除。
ZSet： skor排序（领导板、TTL日历-"延迟"事件）。

Stream： 与消费者群体的稳定队列,"XREADGROUP"/replay-用于webhook, CDC, retraes.

Geo："GEOADD/GEORADIUS"是最近的点/商号。
Bitmap/Bitfield：标志系列（日志，DAU/WAU）。
HyperLogLog：大致唯一的（UU）内存便宜。
Bloom/Cuckoo（模块）：快速可用性检查,减少"MISS"到源。

• RedisJSON（JSON文档），RediSearch（索引/搜索），RedisBloom（概率结构），TimeSeries（度量/聚合）。

3）密钥、TTL和内存策略

tenant:{t}:domain:{d}:{entity}:{id}:v{schema}    region={R}    currency={C}    lang={L}

Version（"vN"）,仅包括有意义的测量（区域/货币/语言/Tenant）。
隔离按键空间。

• 使用TTL矩阵（sec/min/hour）,添加jitter （± 10-20%）,以避免踩踏。
• 对于热键-refresh-ahead和单飞（一个领导者更新）。

• "allkeys-lru/lfu"是没有TTL依赖性的常见凯什。
• "volatile-lru/lfu"仅是TTL的密钥。
• "noeviction"-溢出时写入失败（对于关键队列/计数器更安全）。
• 选择脚本并始终监视"evicted_keys"。

4）交易、管道和脚本

Piplines：降低RTT,分组10-100个命令。
事务（MULTI/EXEC）：不隔离读取,但原子执行数据包。
Optimistic locking： "WATCH key" → "MULTI/EXEC" →验证。
Lua脚本：服务器端原子逻辑（rate limit, locks, composite operation）。

5）队列和总线： List vs Stream

List+"BRPOP"-简单但没有消费者组，offset/replay，对跌倒的抵抗力较弱。
流："XADD → XREADGROUP → XACK"，retry-deadletter（在N分钟内逆转），按键分期。建议用于PSP/KYC网络手册、递延付款/通知。

优先排队：按优先次序排列几个流，消费者首先"吸入"高位。
延迟任务：ZSet在哪里score=timestamp；定期"ZRANGEBYSCORE" ≤现在→转移到Stream。

6）高可用性和扩展

复制：master→replica（read-scale）。

Sentinel： 自动失效主机,检测,客户端URI.

Redis Cluster：在16384插槽上打滑，水平尺度。使用多个结构的密钥包裹在哈希标签"{order： 123}"中。

• 对于kesha/会话, "client-side hashing"支持SDK。
• 对于队列/流-最大限度地减少跨段操作；按域密钥参与。

7）持续性： RDB，AOF和备用

RDB（快照）：更快、更经济；最后几秒钟/分钟丢失的风险。
AOF（期刊）：损失减少；"everysec/always"模式。AOF压缩和周期性重新包装。
混合体：RDB+AOF →快速恢复+中等损失。
Backaps：napshots和AOF到对象存储的副本；定期检查恢复情况。

对于关键队列/幂等,选择AOF 'everysec'+复制。

8）安全和合规性

AUTH/ACL：按应用程序角色，禁止"危险"命令（"FLUSHALL"，"KEYS"）。
TLS到客户端-服务器和节点间链接；固定的egress-IP。
网络细分：私有子网，SG/NACL；仅可从所需服务/neyspace访问。
不要编造秘密；Redis中的PAN/PII仅是令牌/衍生品。
密钥命令：避免"KEYS"-使用"SCAN"。

9）可观察性和SLO

• Latency (P95/P99), `instantaneous_ops_per_sec`, `connected_clients`.
• Hit ratio, evicted_keys, expired_keys.
• Memory: used, fragmentation ratio, RSS, allocator stats.
• Replication lag，AOF/RDB频率和尺寸，分叉时间。
• Streams: PEL (pending entries list), delivery latency, retry count.

• Redis P 99 ≤ 5-10毫秒操作。
• Evictions ≤ 1%/小时 （kesh空间）。
• Stream delivery P99 ≤ 500 мс, retry rate < 2%.

10） FinOps和资源规划

记忆路：测量$/GB-mes RAM vs 节省起源/DB请求。
启用>1-2 KB值压缩（请参阅CPU）。
LFU可以以较小的体积提供更好的命中率。
对于图像/大斑点-不是Redis：使用CDN+对象存储。

11） iGaming/fintech的模式

11.1级限制（滑动窗口,Lua）

想法："INCRBY"在+TTL窗口中；卢阿原子检查极限并放大。

lua
-- KEYS[1]=key ARGV[1]=limit ARGV[2]=ttlSec ARGV[3]=inc local cur = redis. call('INCRBY', KEYS[1], ARGV[3])
if cur == tonumber(ARGV[3]) then redis. call('EXPIRE', KEYS[1], ARGV[2]) end if cur > tonumber(ARGV[1]) then return {0, cur} else return {1, cur} end

11.2请求的难度

键：{request_id} with TTL 24 h,值是结果/状态。在执行操作之前-我们检查是否存在。

11.3个领导板

`ZINCRBY leaderboard:game:{g} score user:{u}` → `ZREVRANGE...WITHSCORES`.

对于区域/tenant的前N，是单独的ZSet或前缀。

11.4 PSP webhook队列

"XADD psp：webhooks……" →消费者团体"XGROUP CREATE psp：webhooks g1$"。
通过PEL扫描（"XPENDING" → "XCLAIM"）转发"挂起"消息。

11.5递延付款

ZSet "payout： due" （score=epoch） → worker定期将现成的元素转移到具有重复数据消除功能的Stream "payout： exec"中。

11.6 Antifrod计数器

"PFADD"（独特）+"INCR"（强度）+地理/ASN标签的组合；手动检查触发器。

12）处理内存和性能

客户连接池；减少RTT（保持活力）。
在团队中更喜欢吹笛。
留意大钥匙（"MEMORY USAGE"，"SCAN"）-最好粉碎对象。
具有少量字段的Hash比许多单个密钥更经济。
如果profit已通过测试确认,则启用io-threads （read-heavy）。
避免在销售中频繁出现"FLUSHDB/ALL"；通过前缀和"UNLINK"进行管理,以便安全删除。

13） Multi-tenant和隔离

单独的群集/实例或logical DB per-tenant（如果负载较小）。
按键/内存配额，分开ACL。
按键中的前缀和namespace上的度量标准。

14）锁定和一致性

SET key val NX PX=ttl是一个简单的mutex。
Redlock：整齐使用；对于分布式关键交易，最好依靠"真相来源"（DB/ledger）和偶数操作。
更喜欢原子操作和Lua而不是"长期"锁定。

15）反模式

大斑点/图像存储是RAM和网络的过热。
仅在Redis中金融不变量（资产负债表）。
"KEYS"和"世界扫描"在销售中。
TTL/jitter的缺失是dogpile到期。
关键队列上的"allkeys-"政策→压力下的数据丢失。
在没有配额和优先事项的情况下，将队列、腰果和会议溷为一谈。
在Cluster中运行不同插槽密钥的Lua脚本。

16）实施支票

1.定义角色：kesh/会话、队列/流、计数器/限制-按实例/群集排列。
2.在任务下选择maxmemory-policy；设置限值和监视事件。
3.键键，方案版本，TTL矩阵+jitter；单飞顶级钥匙。
4.对于队列-Streams（组、转发、DLQ）,对于延迟的-ZSet+迁移。
5.HA：复制+Sentinel或Redis Cluster；检查客户的失败。
6.持续性：脚本下的RDB/AOF；定期备份和恢复测试。
7.安全性：ACL，TLS，私人网络，禁止危险命令。
8.可观察性：latency，ops/sec，memory，evictions，repliclag，stream PEL。
9.FinOps：内存配置文件，大密钥，压缩，LFU；避免大斑点的redis。
10.模式文档（极限，等效性，领导板）和负载测试。

结果

Redis是速度的"多功能瑞士刀"：凯什，队列，计数器，领导板，地质和概率结构。它的力量在于正确选择数据结构，TTL/致残学科，操作原子性，以及精心设计的NA/持久性和可观察性。在毫秒和高RPS很重要的地方使用Redis，同时将关键不变量（金钱，会计）留给"真相来源"-因此平台将保持快速和可靠。