Feed流系统重构-架构篇

重构,于我而言,很大的快乐在于能够解决问题。

第一次重构是重构一个c#版本的彩票算奖系统。当时的算奖系统在开奖后,算奖经常超时,导致用户经常投诉。接到重构的任务,既兴奋又紧张,花了两天时间,除了吃饭睡觉,都在撸代码。重构效果也很明显,算奖耗时从原来的1个小时减少到10分钟。

去年,我以架构师的身份参与了家校朋友圈应用的重构。应用麻雀虽小,五脏俱全,和诸君分享架构设计的思路。

01 应用背景

1. 应用介绍

移动互联网时代,Feed流产品是非常常见的,比如我们每天都会用到的朋友圈,微博,就是一种非常典型的Feed流产品。
Feed(动态):Feed流中的每一条状态或者消息都是Feed,比如朋友圈中的一个状态就是一个Feed,微博中的一条微博就是一个Feed。
Feed流:持续更新并呈现给用户内容的信息流。每个人的朋友圈,微博关注页等等都是一个Feed流。

家校朋友圈是校信app的一个子功能。学生和老师可以发送图片,视频,声音等动态信息,学生和老师可以查看班级下的动态聚合。

为什么要重构呢?

▍ 代码可维护性

服务端端代码已经有四年左右的历史,随着时间的推移,人员的变动,不断的修复Bug,不断的添加新功能,代码的可读性越来越差。而且很多维护的功能是在没有完全理解代码的情况下做修改的。新功能的维护越来越艰难,代码质量越来越腐化。

▍ 查询瓶颈
服务端使用的mysql作为数据库。Feed表数据有两千万,Feed详情表七千万左右。
服务端大量使用存储过程(200+)。动态查询基本都是多张千万级大表关联,查询耗时在5s左右。DBA同学反馈sql频繁超时。

2. 重构过程

《重构:改善既有代码的设计》这本书重点强调: “不要为了重构而重构”。 重构要考虑时间(2个月),人力成本(3人),需要解决核心问题。

1、功能模块化, 便于扩展和维护

2、灵活扩展Feed类型, 支撑新业务接入

3、优化动态聚合页响应速度

基于以上目标, 我和小伙伴按照如下的工作。

1)梳理朋友圈业务,按照清晰的原则,将单个家校服务端拆分出两个模块

  • 1 space-app: 提供rest接口,供app调用
  • 2 space-task: 推送消息, 任务处理

2)分库分表设计, 去存储过程, 数据库表设计

数据库Feed表已达到2000万, Feed详情表已达到7000万+。为了提升查询效率,肯定需要分库分表。但考虑到数据写入量每天才2万的量级,所以分表即可。

数据库里有200+的存储过程,为了提升数据库表设计效率,整理核心接口调用存储过程逻辑。在设计表的时候,需要考虑shardingKey冗余。 按照这样的思路,梳理核心逻辑以及新表设计的时间也花了10个工作日。

产品大致有三种Feed查询场景

  • 班级维度: 查询某班级下Feed动态列表
  • 用户维度:查询某用户下Feed动态列表
  • Feed维度: 查询feed下点赞列表

3)架构设计
在梳理业务,设计数据库表的过程中,并行完成各个基础组件的研发。

基础组件的封装包含以下几点:

  • 分库分表组件,Id生成器,springboot starter
  • rocketmq client封装
  • 分布式缓存封装

03 分库分表

3.1 主键

分库分表的场景下我选择非常成熟的snowflake算法。

第一位不使用,默认都是0,41位时间戳精确到毫秒,可以容纳69年的时间,10位工作机器ID高5位是数据中心ID,低5位是节点ID,12位序列号每个节点每毫秒累加,累计可以达到2^12 4096个ID。

我们重点实现了12位序列号生成方式。中间10位工作机器ID存储的是

 Long workerId = Math.abs(crc32(shardingKeyValue) % 1024)
 //这里我们也可以认为是在1024个槽里的slot

底层使用的是redis的自增incrby命令。

   //转换成中间10位编码
   Integer workerId = Math.abs(crc32(shardingKeyValue) % 1024);
   String idGeneratorKey = 
   IdConstants.ID_REDIS_PFEFIX + currentTime;
   Long counter = atomicCommand.incrByEx(
    idGeneratorKey,
    IdConstants.STEP_LENGTH,
    IdConstants.SEQ_EXPIRE_TIME);
   Long uniqueId = SnowFlakeIdGenerator.getUniqueId(
      currentTime, 
      workerId.intValue(), 
   counter);

为了避免频繁的调用redis命令,还加了一层薄薄的本地缓存。每次调用命令的时候,一次步长可以设置稍微长一点,保持在本地缓存里,每次生成唯一主键的时候,先从本地缓存里预取一次,若没有,然后再通过redis的命令获取。

3.2 策略

因为早些年阅读cobar源码的关系,所以采用了类似cobar的分库方式。

举例:用户编号23838,crc32(userId)%1024=562,562在区间[512,767]之间。所以该用户的Feed动态会存储在t_space_feed2表。

3.3 查询

带shardingkey的查询,比如就通过用户编号查询t_space_feed表,可以非常容易的定位表名。

假如不是shardingkey,比如通过Feed编号(主键)查询t_space_feed表,因为主键是通过snowflake算法生成的,我们可以通过Feed编号获取workerId(10位机器编号), 通过workerId也就确定数据位于哪张表了。

模糊查询场景很少。方案就是走ES查询,Feed数据落库之后,通过MQ消息形式,把数据同步ES,这种方式稍微有延迟的,但是这种可控范围的延迟是可以接受的。

3.4 工程

分库分表一般有三种模式:

  1. 代理模式,兼容mysql协议。如cobar,mycat,drds。
  2. 代理模式,自定义协议。如艺龙的DDA。
  3. 客户端模式,最有名的是shardingsphere的sharding-jdbc。

分库分表选型使用的是sharding-jdbc,最重要的原因是轻便简单,而且早期的代码曾经看过一两次,原理有基础的认识。

核心代码逻辑其实还是蛮清晰的。

ShardingRule shardingRule = new ShardingRule(
shardingRuleConfiguration, 
customShardingConfig.getDatasourceNames());
DataSource dataSource = new ShardingDataSource(
   dataSourceMap,
   shardingRule, 
   properties);

请注意: 对于整个应用来讲,client模式的最终结果是初始化了DataSource的接口

  1. 需要定义初始化数据源信息
    datasourceNames是数据源名列表,
    dataSourceMap是数据源名和数据源映射。
  2. 这里有一个概念逻辑表和物理表。
逻辑表 物理表
t_space_feed (动态表) t_space_feed_0~3
  1. 分库算法:
    DataSourceHashSlotAlgorithm:分库算法
    TableHashSlotAlgorithm:分表算法
    两个类的核心算法基本是一样的。

    • 支持多分片键
    • 支持主键查询
  2. 配置shardingRuleConfiguration。
    这里需要为每个逻辑表配置相关的分库分表测试。
    表规则配置类:TableRuleConfiguration。它有两个方法

  • setDatabaseShardingStrategyConfig
  • setTableShardingStrategyConfig

整体来看,shardingjdbc的api使用起来还是比较流畅的。符合工程师思考的逻辑。

04 Feed流

班级动态聚合页面,每一条Feed包含如下元素:

  • 动态内容(文本,音频,视频)
  • 前N个点赞用户
  • 当前用户是否收藏,点赞数,收藏数
  • 前N个评论

聚合首页需要显示15条首页动态列表,每条数据从数据数据库里读取,那接口性能肯定不会好。所以我们应该用缓存。那么这里就引申出一个问题,列表如何缓存?

4.1 列表缓存

列表如何缓存是我非常渴望和大家分享的技能点。这个知识点也是我 2012 年从开源中国上学到的,下面我以「查询博客列表」的场景为例。

我们先说第1种方案:对分页内容进行整体缓存。这种方案会 按照页码和每页大小组合成一个缓存key,缓存值就是博客信息列表。 假如某一个博客内容发生修改, 我们要重新加载缓存,或者删除整页的缓存。

这种方案,缓存的颗粒度比较大,如果博客更新较为频繁,则缓存很容易失效。下面我介绍下第 2 种方案:仅对博客进行缓存。流程大致如下:

1)先从数据库查询当前页的博客id列表,sql类似:

select id from blogs limit 0,10 

2)批量从缓存中获取博客id列表对应的缓存数据 ,并记录没有命中的博客id,若没有命中的id列表大于0,再次从数据库中查询一次,并放入缓存,sql类似:

select id from blogs where id in (noHitId1, noHitId2)

3)将没有缓存的博客对象存入缓存中

4)返回博客对象列表

理论上,要是缓存都预热的情况下,一次简单的数据库查询,一次缓存批量获取,即可返回所有的数据。另外,关于 缓 存批量获取,如何实现?

  • 本地缓存:性能极高,for 循环即可
  • memcached:使用 mget 命令
  • Redis:若缓存对象结构简单,使用 mget 、hmget命令;若结构复杂,可以考虑使用 pipleline,lua脚本模式

第 1 种方案适用于数据极少发生变化的场景,比如排行榜,首页新闻资讯等。

第 2 种方案适用于大部分的分页场景,而且能和其他资源整合在一起。举例:在搜索系统里,我们可以通过筛选条件查询出博客 id 列表,然后通过如上的方式,快速获取博客列表。

4.2 聚合

Redis:若缓存对象结构简单,使用 mget 、hmget命令;若结构复杂,可以考虑使用 pipleline,lua脚本模式

这里我们使用的是pipeline模式。客户端采用了redisson
伪代码:

//添加like zset列表
 ZsetAddCommand zsetAddCommand = new ZsetAddCommand(LIKE_CACHE_KEY + feedId, spaceFeedLike.getCreateTime().getTime(), userId);
pipelineCommandList.add(zsetAddCommand);
//设置feed 缓存的加载数量
HashMsetCommand hashMsetCommand = new HashMsetCommand(FeedCacheConstant.FEED_CACHE_KEY + feedId, map);
pipelineCommandList.add(hashMsetCommand);
//一次执行两个命令
List<?> result = platformBatchCommand.executePipelineCommands(pipelineCommandList);
  1. 根据班级编号查询出聚合页面feedIdList;
  2. 根据列表缓存的策略分别加载 动态,点赞,收藏,评论数据,并组装起来。
模块 redis存储格式
动态 HASH 动态详情
点赞 ZSET 存储userId ,前端显示用户头像,用户缓存使用string存储
收藏 STRING 存储userId和FeedId的映射
评论 ZSET 存储评论Id,评论详情存储在string存储

缓存全部命中的情况下,动态聚合页查询在5毫秒以内,全部走数据库的情况下50~80ms之间。

05 消息队列

我们参考阿里ons client 模仿他的设计模式,做了rocketmq的简单封装。

封装的目的在于方便工程师接入,减少工程师在各种配置上心智的消耗。

  1. 支持批量消费和单条消费;
  2. 支持顺序发送;
  3. 简单优化了rocketmq broker限流情况下,发送消息失败的场景。

写在最后

这篇文字主要和大家分享应用重构的架构设计。
其实重构有很多细节需要处理。

  1. 数据迁移方案
  2. 团队协作,新人培养
  3. 应用平滑升级

每一个细节都需要花费很大的精力,才可能把系统重构好。

posted @ 2022-01-13 22:18  勇哥编程游记  阅读(783)  评论(4编辑  收藏  举报