mengml_smile的博客

Key分片：将热点商品的库存拆分为多个Key（如item_stock_1, item_stock_2），分散访问压力。本地缓存+延迟双删：在服务节点本地缓存库存数据，结合延迟删除策略减少Redis访问。缓存预热：在秒杀开始前将库存数据加载到Redis并禁止直接访问DB。扣库存成功 → 发送消息到MQ → 订单服务消费并生成预订单。支付服务异步回调确认，更新订单状态并扣减数据库库存。

计费：计算费用，一句话概括就是：根据不同的计费规则，计算一笔订单/交易中，不同参与角色应该分配多少利益（主要为钱），简单说就是一个怎么分蛋糕的事情，起到承上启下的作用。结算：结算平台与计费系统作为清结算体系中重要的组成部分，计费平台把订单的业务信息流转变成转化为资金信息流，结算平台把资金信息流转化成实实在在的结算资金流。

参考

数据血缘落地实践

直接点讲，就是大部分（80%以上）的需求，都用DWS的表来支持就行，DWS支持不了的，就用DWM和DWD的表来支持，这些都支持不了的极少一部分数据需要从原始日志中捞取。在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。“面向主题的”数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。

基于标签的推荐系统必须要解决的4个核心问题

数据中台实战：以圆猿买手为案例谈如何从0到1搭建实时标签引擎

数据采集实战：商品详情页数据埋点

Oauth2.0 作用: 客户端和资源所有者 颁发令牌 授权机制 三方: 1、服务提供方 2、用户 3、客户端 授权码 先申请授权码 后用其获取令牌 优势 避免令牌泄漏 前端 授权码 后端存储令牌 流程 A前端请求B 请求授权码 B要求用户登录 后问用户是否同意给予A网站授权 同意跳转redirect_uri A拿到授权码在后端向B请求令牌 B颁发令牌 access_token https://b.com/oauth/authorize? response_type=code&am