需求背景 促销活动中,多个业务方都有发放优惠券的需求,且对发券的 QPS 量级有明确的需求。 所有的优惠券发放、核销、查询都需要一个新的系统来承载。 因此
偶然看到下面这篇文章,写于2010年。站在2023这个时间点,觉得可以在自己的理解上补充一下,TODO 原文 https://timyang.net/architecture/microblog-design-qcon-beijing/ 用户规模影响设计,具体是指用户数
背景 在支付系统:MySQL 分片 我们讨论了如何进行分库分表。 由于各种原因,我们的数据库负载会随着时间的推移而增加,比如: 用户数量和流量的增长。
缓存使用场景 缓存用户信息 - 如 钱包余额 作为消息队列 分布式锁 - Cache lock 防止异步消息重复消费 限流 - rate limit Geohash - 查询地理范围 布隆过滤 - 检测user是否参加过
在支付系统中,数据库则是最容易产生性能瓶颈的组件。 在本文中,我们将讨论支付服务是如何在大规模下对MySQL存储的数据进行分库分表,以满足我们
PCI DSS PCI DSS的六大要求和12项操作细则如下。 要求一:建立和维护安全的网络 1)安装并维护防火墙配置以保护持卡人数据。 2)系统口令和其他安全参数
“微服务”是怎么来的 也不知道过去几年这股奇怪的“微服务”风潮是怎么起来的。在我看来,微服务的适用场景非常有限。 许多巨头互联网公司的核心业务逐
本文主要是从支付架构、支付流程分析、支付核心逻辑、支付基础服务、支付安全、压力测试6个方面来详细讲述支付系统架构设计。 支付系统框架 架构的定义
支付系统的一大挑战:高并发下怎么做余额扣减;并发扣款,如何保证数据的一致性? 高并发扣减思路 分库分表 合并请求,在保证事务的前提下,将多个扣款请
CAP 理论 在分布式系统领域,有一个理论,对于分布式系统的设计影响非常大,那就是 CAP 理论,即对于一个分布式系统而言,它是无法同时满足 Consiste
你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处。 为什么使用消息队列?