测试

背景

基于当前遇到的问题。

1. 商品模块核心接口目前是基于odp的，会很耗资源，单pod压测有上限。

2. redis存在热点数据的问题。（秒杀同一个商品的情况）

3. 接口耗时过长。

4. 目前组装数据会在c端接口组装，商品本身就是读多写少，可以后台组装好之后统一输出。

指标

• 接口压测指标，单pod并发？（减少资源数量）

1. 1. 理论上单pod在2千左右。 10w需要50个pod。（压测获取）

• 耗时降低时间？保持在10毫秒内返回 。（压测获取）

1. 1. 1个/2个/5个 sku压测数据。

1. 服务启动时间？ （同步（热点数据）+异步（其他上架数据））

1. 1. 48029 w 上架数据。

2. 每天变更的数据多少个？ 1w 左右接口同步的。正常人工修改2000条以内，所以变更很少。
3. 热点数据有多少？

1. 1. 每天访问的商品数量（写本是缓存。每隔一段时间上报给redis，redis会记录bitmap，说明是热点数据）。

4. 穿透率

1. 1. 穿透redis 保障在 1%左右。

优化收益

1. 减少资源占用 （pod数量480个）

2. 解决热点数据的问题。

3. 减少接口响应时间。

4. 缩短链路长度。

本次改造涉及接口：kv2 + kv1 + 快照v2

整体架构

流程图

1. 全量数据（热点数据），服务启动的时候，访问db，拉取上架数据，写入到本地文件（本地缓存读取没有才会加载）
2. 增量数据（热点数据），根据偏移量增量更新。

1. 1. pod第一次初始化之后会记录最新的时间，后续跟进时间来作为下一次的偏移量（表中的update_time）。
   2. pod拉取根据上一次的偏移量，查找哪些skuid变更了，重新写入本地文件
   3. 洗数据的场景，涉及大批量的数据改动。

1. 1. 1. 不做任何改动，会有一点延迟，如果晚上跑是可接受的。

• 访问未上架的商品会穿透文件不会写到文件中，理论上文件都是上架商品。
• 热点数据：

1. 1. 第一版 上架数据 。
   2. 第二版 接口增加上报功能。每隔一段时间上报。

1. 1. 1. 最简单的方法写到redis的bitmap中，使用开关控制（大促期间关掉上报功能）。

存储方案：

本地缓存（30秒）skuId => all data（1次调用组装之后的数据）

文件存储(无时间限制)

1. sku文件,
2. spu文件，
3. shop文件，（全量，1587）
4. 类目文件，（全量数据，1700）
5. 索引文件（redis），作用: 1. 为了加快验证和更新数据使用 （skuId => version） 2. 访问快照如果是最新快照会读取本地文件。

1. 1. sku_skuId => [1,2,3,4] md5 update_time
   2. spu_spuId => [1,2,3,4] md5 update_time

skuInfo

方案一（暂不考虑）

每次数据变更会记录到db中去（新的聚合之后的快照数据）

1. 1. id,skuId, md5, version=[1,2,3,4,5]，kv1Data, kv2Data, update_time（偏移量）
   2. id,spuId, md5, verrsion=[1,2,3,4], spuName, data,update_time

文件

目录划分 0-99/0-99/skuId （最后四位计算）。

kv1 => json

kv2 => json

id(表的id)

缺点：存储多了一份。

优点：穿透之后直接查db查询不需要额外的组装放到缓存中去。比较方便。c端不用写复杂的组装逻辑。

方案二（推荐）

复用当前的db和redis存储。（偏移量使用现有goodsSku中的更新使劲）

kv1和kv2的接口通过计算得出（和原有计算逻辑保持一致）

穿透查目前的redis和db数据。

缺点：前期并行阶段改代码需要改2个地方。

优点：1. 不用做单独的额外存储，穿透之后复用当前redis+db的方案。

2. 启动可以不需要刷新数据，服务器启动之后异步更新本地文件。

文件存储

目录划分 0-99/0-99/skuId （最后四位计算）。

data => db中的json数据

spuInfo

目录划分 0-99/0-99/spuId （最后四位计算）

data => json

spu变更会导致大量sku的变更，通过索引文件的md5值对比，可以过滤掉很大一部分数据。

shopInfo

目录划分 0-99/shopId

id

versions

md5

agencyId

channelId

shopPayMix

storeType

类目

存储全量数据（数据比较少tblGoodsTags 1606 tblGoodsField 368条）

访问流程

其他：

一致性保障

1. 全量文件数据比对。（30分钟，和redis和db比对，根据数据进行调整。）
2. 全量接口数据比对。（30分钟，会单独访问每一个skuid进行比对数据。）
3. 如果根据偏移量更新发现偏移量差超过30秒会暂时报警处理，一致性延迟不能超出1分钟。

切换方案

使用方统计

切换顺序

1. 商品内部接口切换。
2. 通过网关切换。
3. 调用方直接替换链接。