1.核心功能
•监控预警•EventBus 消息总线[1]•Redis 库存操作Lua
2.接口性能
集群 1.5w
tps
单机 400
tps
120w 日活
3.抖音接口文档
https://developer.open-douyin.com/docs/resource/zh-CN/dop/develop/openapi/life-service-open-ability/life.capacity/tripartite.code/precreateorder
监控预警实现
企业微信机器人 webhook
protected void msgSend(String wxUrl, IAlertMsg msg, WxMsg wxRobotMsg) {
HttpHeaders httpHeaders = new HttpHeaders();
httpHeaders.setContentType(MediaType.APPLICATION_JSON);
httpHeaders.setConnection("Keep-Alive");
HttpEntity<String> httpEntity = new HttpEntity<>(JSONObject.toJSONString(wxRobotMsg), httpHeaders);
String reponseMsg = restTemplate.postForObject(wxUrl, httpEntity, String.class);
log.debug("{} >> {}", msg, reponseMsg);
}
EventBus 介绍
事务拆分
•Saga分布式事务[2]
阶段性重试
•XxLJob 重试
框架设计
Redis 库存处理
方案
•List 兑换码池•Set 导入去重•String 余额、总库存管理
local CDKey_QUEUE = KEYS[1]
local CDKey_SET = KEYS[2]
local CDKey_SCRIPT_TYPE = KEYS[3]
local CDKeys_PARAMS = ARGV
local retAddCDKey = 0
local retGetCDKey = {}
local function addCDKey()
for i, v in ipairs(CDKeys_PARAMS) do
local addOk = redis.call("SADD", CDKey_SET, v)
if addOk == 1 then
redis.call("LPUSH", CDKey_QUEUE, v)
retAddCDKey = retAddCDKey + 1
end
end
end
local function getCDKey()
local num = tonumber(CDKeys_PARAMS[1])
for i = 1, num do
local v = redis.call("RPOP", CDKey_QUEUE)
if type(v) == 'boolean' then
else
if v ~= nil then
table.insert(retGetCDKey, v)
end
end
end
if #retGetCDKey ~=0 and num ~= #retGetCDKey then
for i, v in ipairs(retGetCDKey) do
redis.call("LPUSH", CDKey_QUEUE, v)
end
retGetCDKey = {}
end
end
if CDKey_SCRIPT_TYPE == '0{yes}' then
addCDKey()
return retAddCDKey
else
getCDKey()
return retGetCDKey
end
问题归纳
1.调用抖音验券接口限制
一张券在核销时会暂时锁住这个订单
所以订单中的其他券在未解锁之前就核销 肯定会报错的
建议同一笔订单中的券一起核销 或者一张一张验券
2.抖音调用服务商发券接口
偶发情况,抖音不会调用【预下单】发券接口需进行创建订单操作
偶发情况,抖音不会调用【预下单】发券接口需进行创建订单操作
技术文章分享
凤凰架构[1]
•可靠事件队列
最终一致性的概念是 eBay 的系统架构师 Dan Pritchett 在 2008 年在 ACM 发表的论文《Base: An Acid Alternative》中提出的,该论文总结了一种独立于 ACID 获得的强一致性之外的、使用 BASE 来达成一致性目的的途径。BASE 分别是基本可用性(Basically Available)、柔性事务(Soft State)和最终一致性(Eventually Consistent)的缩写。BASE 这提法简直是把数据库科学家酷爱凑缩写的恶趣味发挥到淋漓尽致,不过有 ACID vs BASE(酸 vs 碱)这个朗朗上口的梗,该论文的影响力的确传播得足够快。在这里笔者就不多谈 BASE 中的概念问题了,虽然调侃它是恶趣味,但这篇论文本身作为最终一致性的概念起源,并系统性地总结了一种针对分布式事务的技术手段,是非常有价值的。
我们继续以本章的场景事例来解释 Dan Pritchett 提出的“可靠事件队列”的具体做法,目标仍然是交易过程中正确修改账号、仓库和商家服务中的数据,图 3-7 列出了修改过程的时序图。
扫码加群
References
[1]
EventBus 消息总线: http://rabbitmq.mr-ping.com/
[2]
Saga分布式事务: https://cloud.tencent.com/developer/article/1839642[3]
凤凰架构: https://icyfenix.cn