架构案例参考
本文收集了一些其他文章中所写的，在做系统设计时候的对于一些案例的思考。
在腾讯 QQ 的红包活动中，对于活动的展示、错峰的内容、预下载资源的内容等，都是采取的全局配置策略进行全局控制的。而为了让用户能够错峰进入活动，避免给后台带来瞬间冲击的问题，其采用 uid % gap 的方式对用户的进入时间进行了错峰划分，但是这样带来的问题是有可能身边的人都看到活动入口了，但是自己还看不到入口，所以还应该将地理位置因素也考虑进去：
- 根据用户地理位置 adcode 和错峰配置进行映射，得到映射后的分区索引
i； - 计算得到一次错峰时间：
T1 = T0 + i*interval； - 对于同一批次的用户，通过随机时间，将这些用户随机均匀地映射分布到对应较小的时间段内，计算得到二次错峰时间：
T2 = T1 + hash(uin)%interval； - 得到的二次错峰时间
T2即为用户实际可以看到入口参与活动的时间：T = T2； - 对于地理位置一次错峰可能出现的异常情况，如用户未授权获取地理位置（占比30%左右）、国外用户无adcode未匹配到分区索引等，客户端可采取一定的兜底策略，如根据用户账号uin进行随机映射到某个分区：
i = hash(uin) % regions.count。
而在活动期间产生的数据的上报流程如下所示，可以看到其上报的时机、上报的方式等都支持非常灵活的调整策略：
而在上报的链路中，SSO接入层和上报服务后台也分别用过载策略和降级策略来应对过载的风险，其后台接口中包含了 reportLevel 和 reportLevelTime 这两个上报降级信息字段。
