知名公司功能模块的实现笔记

Storage

微信支付的交易记录

之前kv,每个用户一个key(相当于redis list),这样问题是:

  • value会大
  • 无法根据条件filter value

改进后:
没有用户多个value,其中1个root value,保存metadata,其他value为data
多value解决了以前单value大的问题,但:

  • 多了一次请求
    先root,再value
  • root成为新瓶颈
    • 可以把root也变成一个link list
      按照时间倒排,新的是head,老的是tail
    • 但越以前的数据,越慢

柔性事务如何解决分布式事务

  1. 引入日志和补偿机制
    正向补偿:重试
    逆向补偿:undo log

无锁修改库存

可以记录增件变化的明细表,避免所有事务对同一行更新,避开hotspot。
例如,下订单时,记录库存变化明细;支付成功时,真正进行update。为了防止超卖,在支付前,扫描库存明细表计算目前真正的库存,此时可能会库存不够,那就不让支付了

数据库的高可靠、强一致

  1. 数据库异步复制,主备数据无法保证一致
    主死后,判断哪些用户最近没有做过主库update,他们可以在从库上进行新的操作;否则,在数据库恢复前不允许写操作

  2. Failover库
    订单编号里有1位,表示存放在主库还是failover库。当主死了,健康检查发现,通知订单编号生成器,它修改该bit,DAL会
    把后续的数据写入failover库。
    主库恢复后,健康健康发现,修改bit,DAL后续继续写主库。
    经过一段时间后,主库+failover库的记录都会迁移到历史库。
    failover机制,使得主备切换期间,仍然可以对外服务,用户不中断

  3. 业务数据可以归为3大类

  • 状态型
    读写比例差不多
  • 流水型
    例如订单
  • 配置型
    读多写少,不要求严格的一致性

算法

biparties graph(二部图/二分图)

对多种查询条件进行归并缓存,提高缓存命中率

查询条件:

1
2
3
4
(row1, row5) => (field3, field7)
(row2) => (field2, field4)
(row3) => (field3, field5)
(row4, row6) => (field1, field4, field8)

利用二部图把图切分,把零散查询归并为少数集中的查询

M$ Cloud Design Pattern

  • cache-aside
  • ciruit breaker
  • compensating transation
  • competing consumers
  • CQRS
  • event sourcing
  • external configuration store
  • federated identity
  • gatekeeper(gateway)
  • health endpoint monitoring
  • index table
  • lead election
  • materialized view
  • pipes and filters
  • priority queue
  • queue-based load leveling
  • retry
  • runtime reconfiguration
  • scheduler agent supervisor
  • sharding
  • static content hosting
  • throttling
  • valet key
Share Comments