分布式
idSnowflake方案时间戳+workid+自增序列号(12)leaf分业务 ，分段从数据库里发号器拿号
微博
数据量大1.1 redis大小经过设计， 改造redisredis (weiboid, (转发，评论，点赞，浏览))1.2 内存保存热数据，磁盘保存冷数据冷数据dump到磁盘，需要使用时由单独I/O线程异步将SSD磁盘中加载到单独的cold cache中。pika,ssdb1.3 写时批量处理，参考kafka2. 未读消息2.1 系统未读消息每个用户维护已读。消息ID，一个月没登录的用户或者新用户无消息ID。 维护最新系统ID消息，用户查看页面时候相减拉取。2.2 消息流消息redis 用户发的微博：(userId, 微博数量)用户已读的微博：userId-snapshot， hashMap-(userId, 读到的微博数);mget获取hashMap userId的微博数。3. 信息流3.1 推模式如pyq，有限场景，好友互相关注，且上限为5k。Feed表 feedid/创建人id/内容/创建时间/微博状态/微博来源TimeLine表 用户Id/FeedId/创建时间根据TimeLine表，读取FeedId，再判断删除，关注关系。3.2 拉模式缓存5天内的微博，带宽瓶颈，所以做多副本缓存分流3.3 折中大V 50w关注以上，推活跃用户（定长，lru），几天内有操作的用户
秒杀系统
高并发设计原则 数据尽量少 请求数尽量少 路径要短 依赖要少 不要单点
- 静态数据处理 用户浏览器缓存； CDN节点缓存——带宽充足，主站较远，与主站通讯良好 Ngnix 动静分离 「防单点问题，可以一组服务器做缓存」 服务端缓存
数据可以进行gzip压缩。 2. 热点数据 热点数据获取： 静态获取： 商家报名，大数据离线分析 top n 动态获取： 做一个热点系统，系统根据收集Nginx和rpc的日志，提供分钟级热点数据。 需要的系统调用热点系统，做预热防护。
热点防护： 缓存数秒，LRU淘汰策略； 限制：根据商品ID进行一致性hash，把不同的hash分桶，每个桶一个处理队列，防止热点数据占用过多资源。 隔离： 业务隔离-商家加入营销活动； 系统隔离-不同域名，分组布置； 数据隔离：单独缓存，单独mysql
-
流量削峰 无损：排队、答题、分层过滤 有损： 限流、机器负载保护
-
扣减库存 预扣（场景，不紧急，可以补货） 下单库存保留10min，超时自动释放 付款前校验该订单库存是否保留，没再次预扣 库存不足 1-不让付，2-补货 支付成功 - 扣库存
秒杀 直接下单锁。
此类可以不保留库存 经常下单不付款的人。打标。 某些类目设置最大购买数量。 重复下单不付款，次数限制。
sku单一 缓存库存 sku复杂 - 数据库， 应用层ID hash排队；数据库ID 排队
