应该不是大家猜测说的情况（如图所示）。原理很简单：
①如果1300万人每天早中晚三个高峰都用小程序从云端拉下来一张200KB的健康码图片而不是拉下来JSON数据然后本地生成二维码，那一码通服务早就崩了一万次了。健康码每天零点开始都是新的。昨天的本地图片缓存都失效了。
②二维码图片本身很小几KB，至多十几KB。大家传来传去的“1MB图片压到200K”很可能指的是健康码小程序在用户首次采集信息的时候自拍上传的那张头像照片，压到200KB之后，下次小程序客户端版本更新后会从云端拉下来头像照片并放入本地缓存。
当天健康码第一次生成是最危险的，它的请求曲线应该跟我们做社餐做团餐收银一样，容易出现快速攀升的“秒杀”场景和“重试风暴，尤其是周一早高峰。
正常的做法是按居住地散列出很多单元格，每个单元格里有一套redis集群，可提前灌入接口所需要的热数据；当居住地被卫健委新设为黄红码后，批量刷相应单元格的redis数据即可；当各个核酸检测实验室将核酸结果批量上传平台，也会批量刷新redis数据。
最终小程序客户端从云端（数据从单元格的redis高速取出）一次性拉下两个结果：①健康码状态②最近一次核酸检测结果和检测时间，从而在本地生成健康码图形界面。