知识总结
数亿数据MySQL撑不住,无缝迁移到MongoDB后稳得一批!
3.如何安全地更换数据库
3.1数据回填(负责处理历史数据)
将历史数据分解为子集并通过检查点单独处理它们。 多线程
-1影子写
写入路径中引入了一个新的影子写入器模块。对辅助数据库的写入是异步的。写入失败,重新同步作业。保证2 个数据库之间的一致性。
-2双读和合并
在读取路径中引入了一个新模块 Dual Read and Merge。该模块不是从单个数据库中提供读取请求,而是同时从两个数据库中读取,无论它们的角色如何,合并结果,然后将它们返回给客户端
-3交换数据库
3-1 将 Docstore 上的历史和在线数据生成的 Manifest 与 DynamoDB 上大规模生成的 Manifest 进行比较。如果它们匹配,我们确定所有数据都已成功复制到 Docstore
3-2 一旦读写路径稳定,以 Docstore 为辅助,并且我们对系统性能和可用性感到满意,是时候交换数据库并提升 Docstore 为主了。 (同步写Docstore,异步写DynamoDB,交换角色)
3-3 将 Docstore 提升为主存储后,我们希望慢慢停止到 DynamoDB 的流量并停用它。这分两个阶段完成,首先我们逐渐从 DynamoDB 中删除读取,最终只提供 Docstore 中的读取。请注意,我们会继续对 DynamoDB 的写入进行影子写入,因为我们希望缓慢而安全地消耗流量。我们将系统保持在这种状态大约一周。
-4 最终切换
一旦从 Docstore 完全提供读取服务,就该停止对 DynamoDB 的写入了。一旦停止对 DynamoDB 的写入,我们还强制系统现在通过 config 使用单个数据库运行,这绕过了 Shadow Writer 和 Dual Read and Merge 模块。然后我们可以备份 DynamoDB 表并将其停用,如图 5 中的第 4 阶段所示。
分布式唯一 ID 生成方案浅谈
分布式ID生成方案-snowflake算法
放弃snowflake-我们重新设计了新的分布式ID生成方案
Redis 知识总结
Redis与MySQL双写一致性如何保证?
- Cache-Aside Pattern
- Read-Through/Write-through
- Write-behind
谈一谈热点Key解决方案
抖音支付十万级 TPS 流量发券实践
https://blog.csdn.net/ByteDanceTech/article/details/125419247?spm=1001.2014.3001.5501
实战!如何从零搭建10万级 QPS 大流量、高并发优惠券系统
https://blog.csdn.net/ByteDanceTech/article/details/124207051?spm=1001.2014.3001.5501
2022 春节抖音视频红包系统设计与实现
https://blog.csdn.net/ByteDanceTech/article/details/125342256?spm=1001.2014.3001.5501
春节钱包大流量奖励系统入账及展示的设计与实现
https://blog.csdn.net/ByteDanceTech/article/details/123911428?spm=1001.2014.3001.5501