技术关键字
本文主要是介绍一些在技术范畴内，经常看到的一些关键字，一些话术
关键字
架构
量毛刺
写扩散
把写路径延长一些，读路径缩短一些 ， 目的提`升读性能` 、反规范化
写扩散的缺陷治理
- 实时性差
写扩散虽然对于读取更为有利，但是写的性能也不能太差，所以冗余数据的写入常常是异步的。这就导致写者写完后，读者无法立马读到。这在分布式系统中叫做 读自己写(read-own-write) 问题。
不过这对于大多数应用来说，这都不是什么问题，可以通过下面手段解决：
首先用户写的数据大多不是给自己看，比如推文是给粉丝看的，用户很难发觉其中的延迟；
其次，即使写入的数据是给自己看的，也可以在用户提交完数据后，给用户一个完成页面，一定要用户手动点击退出，才能看到自己写入的数据。比如每次在淘宝提交订单后，都会弹出一个 “订单已完成” 页面，要先点击退出，才能看到订单列表；
- 数据一致性
基本上所有大规模应用都会碰到的问题，但是大家又不得不都做一遍这些老生常谈的保障：
- 数据对账
- 定期全量刷新，纠正增量链路中可能存在的无法核对的错误
- 冗余数据无法写入时(比如数据源故障)，记录错误日志，并实时同步到 odps，等到数据源恢复后根据日志再重新同步。
- 无效数据过多
上面的案例中，写扩散总是从用户维度切入，给每个用户保存一份数据。不禁让人困惑，这数据量会不会太大了？而且大多数用户根本就不会进入这个页面，所以写入的大多数数据都是无效的。
优化这两个问题的方法常被称做 “读写结合”，本质就是在部分场景采用读扩散减少数据冗余，举几个例子:- 对于钉钉审批首页案例，我们可以做好用户分层。对于审批单模板数量较小的企业，还是采用读扩散，只有在审批单数据达到一定规模后，才触发写扩散的方案。”写扩散” 就变成了一个针对大客户的 “高端服务方案”，甚至可以引导用户付费购买超额的模板数量。
- 钉钉视频号中的大 V 拥有几十万的粉丝，大 V 一旦发一条视频，系统就需要在所有粉丝收件箱中推送这条记录，造成了巨大的延迟和系统压力。一个优化方案是，只给高活用户收件箱进行推送(写扩散)，普通用户等在下一次访问时，才即时构建收件箱(读扩散)，这样就能大大减少写入的无效数据。
读扩展
把读路径延长一点，写路径缩短一些 ， 目的提`升写性能` 、规范化
从读写扩散看业务发展的三阶段
第一阶段：业务刚刚启动，还处于探索与试错期。应用倾向于使用读扩散方案快速迭代试错。
第二阶段：业务已经确定可行，很快就进入了快速规模增长期。之前快速迭代留下的坑，都随着规模增长一一暴露。之前读扩散的方案已经很难满足业务要求，架构治理迫在眉睫，开发者们就会使用各种写扩散的技术优化性能，以支持快速增长的规模。
第三阶段：业务的规模已经达到天花板，进入 业务瓶颈期。之前因为规模和营收还在快速增长，所以写扩散带来的存储成本，看起来没什么。但是到了业务瓶颈期，写扩散带来的成本，已经没法带来相应的规模增长了。此时很多开发者们的 OKR 都会变成 “降成本”， 读扩散的方案因为存储成本低，在很多场景又会被重新提出，最终变成 “读写混合” 的方案。
稳定性设计
- 数据对账
网络
- 背压策略
写在最后
后续有新的关键字会陆陆续续补充