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

algorithm, architecture

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