摘要：
系统里有一个工单查询功能，工单表中存放了几千万条数据，且查询工单表数据时需要关联十几个子表，每个子表的数据也是超亿条。 面对如此庞大的数据量，跟前面的冷热分离一样，每次客户查询数据时几十秒才能返回结果，即便我们使用了索引、SQL 等数据库优化技巧，效果依然不明显。 采用了查询分离的解决方案，才得以将 阅读全文
posted @ 2023-03-08 15:39
jiaozg
阅读(30)
评论(0)
推荐(0)
摘要：
阅读全文
posted @ 2023-03-08 15:32
jiaozg
阅读(9)
评论(0)
推荐(0)
摘要：
如何快速实现流量削峰？ 第一步进行的削峰是，先做恶意用户拦截。 基于用户维护设置限制。比如同一个账号在 5 秒内最多可以请求扣减多少次 基于来源 IP 设置限制 手机以及电脑都有唯一编码，如手机的 IMEI、电脑的网卡地址等。可以在限制账号、IP 之外，再增加对这些维度的限制。 增加一定的过滤比例。 阅读全文
posted @ 2023-03-08 11:29
jiaozg
阅读(16)
评论(0)
推荐(0)
摘要：
数据库和纯缓存实现的扣减方案 数据库方案的性能较差； 纯缓存方案虽不会导致超卖，但因缓存不具备事务特性，极端情况下会存在缓存里的数据无法回滚，导致出现少卖的情况。 顺序写的性能更好 在向磁盘进行数据操作时，向文件末尾不断追加写入的性能要远大于随机修改的性能。数据库同样是插入要比更新的性能好。 借力顺 阅读全文
posted @ 2023-03-08 11:14
jiaozg
阅读(39)
评论(0)
推荐(0)
摘要：
架构是面向业务功能、成本、实现难度、时间等因素的取舍，而不是绝对地追求高性能、高并发及高可用等非功能性指标。 纯数据库的方案虽然避免了超卖与少卖的情况，但因采用了事务的方式保证一致性和原子性，所以在 SKU 数量较多时性能下降较明显。 扣减只需要保证原子性即可，并不需要数据库提供的 ACID 在提升 阅读全文
posted @ 2023-03-08 11:08
jiaozg
阅读(48)
评论(0)
推荐(0)
摘要：
读业务的特点是写少读多 扣减类业务的定义，我把关于扣减的实现，需要关注的技术点总结如下： 当前剩余的数量需要大于等于当次需要扣减的数量，即不允许超卖； 对同一个数据的数量存在用户并发扣减，需要保证并发一致性； 需要保证可用性和性能，性能至少是秒级； 一次的扣减会包含多个目标数量； 当次扣减有多个数量 阅读全文
posted @ 2023-03-08 11:01
jiaozg
阅读(26)
评论(0)
推荐(0)
摘要：
数据按路由规则分散后，如何满足无路由字段的多维度富查询？ 为了满足和原有分库维度不一样的查询，最简单的方式是按新的维度异构一套数据 业界应对多维度实时查询的最常见方式便是借助 ElasticSearch 相比数据库，ES 里所有的内容都可以分词建立索引且 ES 不需要保障数据的 ACID 等特性，因 阅读全文
posted @ 2023-03-08 10:56
jiaozg
阅读(113)
评论(0)
推荐(0)
摘要：
分库分表只解决了容量的问题，并没有解决写服务的高可用问题 读服务里，可以采用数据冗余来保障架构的高可用 写冗余需要有满足 CAP 原则的存储支持，而我们知道，CAP 原则最多只能同时满足两个特性，要么 CP 要么 AP 写入业务的目标是成功写入 存储依然使用分库分表，但写入规则则发生了一些变化。它不 阅读全文
posted @ 2023-03-08 10:51
jiaozg
阅读(59)
评论(0)
推荐(0)
摘要：
是否真的要分库？ 容量提升了，但也带来了很多其他问题。比如： 分库数据间的数据无法再通过数据库直接查询了。比如跨多个分库的数据需要多次查询或借助其他存储进行聚合再查询。 分库越多，出现问题的可能性越大，维护成本也变得更高。 无法保障跨库间事务，只能借助其他中间件实现最终一致性 分表后的子表仍在原有库 阅读全文
posted @ 2023-03-08 10:11
jiaozg
阅读(44)
评论(0)
推荐(0)
浙公网安备 33010602011771号