payment

需求背景 促销活动中，多个业务方都有发放优惠券的需求，且对发券的 QPS 量级有明确的需求。 所有的优惠券发放、核销、查询都需要一个新的系统来承载。 因此

背景 在支付系统：MySQL 分片 我们讨论了如何进行分库分表。 由于各种原因，我们的数据库负载会随着时间的推移而增加，比如： 用户数量和流量的增长。

缓存使用场景 缓存用户信息 - 如 钱包余额 作为消息队列 分布式锁 - Cache lock 防止异步消息重复消费 限流 - rate limit Geohash - 查询地理范围 布隆过滤 - 检测user是否参加过

在支付系统中，数据库则是最容易产生性能瓶颈的组件。 在本文中，我们将讨论支付服务是如何在大规模下对MySQL存储的数据进行分库分表，以满足我们

PCI DSS PCI DSS的六大要求和12项操作细则如下。 要求一：建立和维护安全的网络 1）安装并维护防火墙配置以保护持卡人数据。 2）系统口令和其他安全参数

本文主要是从支付架构、支付流程分析、支付核心逻辑、支付基础服务、支付安全、压力测试6个方面来详细讲述支付系统架构设计。 支付系统框架 架构的定义

支付系统的一大挑战：高并发下怎么做余额扣减；并发扣款，如何保证数据的一致性？ 高并发扣减思路 分库分表 合并请求，在保证事务的前提下，将多个扣款请

你们公司有个什么业务场景，这个业务场景有个什么技术挑战，如果不用 MQ 可能会很麻烦，但是你现在用了 MQ 之后带给了你很多的好处。 为什么使用消息队列?