前言

高并发下如何设计秒杀系统？这是一个高频面试题。这个问题看似简单，但是里面的水很深，它考查的是高并发场景下，从前端到后端多方面的知识。

秒杀一般出现在商城的促销活动中，指定了一定数量（比如：10个）的商品（比如：手机），以极低的价格（比如：0.1元），让大量用户参与活动，但只有极少数用户能够购买成功。这类活动商家绝大部分是不赚钱的，说白了是找个噱头宣传自己。

虽说秒杀只是一个促销活动，但对技术要求不低。下面给大家总结一下设计秒杀系统需要注意的9个细节。

前言

接口幂等性问题，对于开发人员来说，是一个跟语言无关的公共问题。本文分享了一些解决这类问题非常实用的办法，绝大部分内容我在项目中实践过的，给有需要的小伙伴一个参考。

不知道你有没有遇到过这些场景：

1. 我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。
2. 我们的项目中为了解决接口超时问题，引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果（此时有可能已经成功了），为了避免返回错误的结果（这种情况不可能直接返回失败吧？），于是对该请求重试几次，这样也会产生重复的数据。
3. mq消费者在读取消息时，有时候会读取到重复消息（至于什么原因这里先不说），从而导致产生了重复的数据。

没错，这些都是幂等性问题。

接口幂等性是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

这类问题多发于接口的：

• insert操作，这种情况下多次请求，可能会产生重复数据。
• update操作，如果只是单纯的更新数据，比如：update user set status=1 where id=1，是没有问题的。如果还有计算，比如：update user set status=status+1 where id=1，这种情况下多次请求，可能会导致数据错误。

前言

在高并发系统当中，分库分表是必不可少的技术手段之一，同时也是BAT等大厂面试时，经常考的热门考题。

你知道我们为什么要做分库分表吗？

这个问题要从两条线说起：垂直方向 和 水平方向。

前言

在实际工作中，我们需要经常跟第三方平台打交道，可能会对接第三方平台API接口，或者提供API接口给第三方平台调用。

那么问题来了，如果设计一个优雅的API接口，能够满足：安全性、可重复调用、稳定性、好定位问题等多方面需求？

今天跟大家一起聊聊设计API接口时，需要注意的一些地方，希望对你会有所帮助。

前言

在面试时，经常会被问一个问题：如何防止别人恶意刷接口？

这是一个非常有意思的问题，防范措施挺多的。今天这篇文章专门跟大家一起聊聊，希望对你会有所帮助。

前言

最近知识星球中有位小伙伴问了我一个问题：如何快速同步第三方平台数据？

他们有个业务需求是：需要同步全国34个省市，多个系统的8种业务数据，到他们公司的系统当中。

他们需求同步全量的数据和增量的数据。

全量的数据主要是针对多个系统的历史数据，大概有几千万数据，只需要初始化一次即可。

而增量的数据，是系统后续变更的数据。

这个需求其实不简单，至少有以下难点：

1. 不能直接访问第三方数据库。
2. 不能将历史数据导出到excel中，有泄露数据的风险。
3. 如何快速同步历史数据？
4. 增量数据如何处理？
5. 接口需要做限流吗？
6. 增量数据如何校验数据的一致性？

带着这些问题，开始今天的文章之旅。

前言

前几天，知识星球中有位小伙伴，问了我一个问题：加密的手机号如何模糊查询？

我们都知道，在做系统设计时，考虑到系统的安全性，需要对用户的一些个人隐私信息，比如：登录密码、身份证号、银行卡号、手机号等，做加密处理，防止用户的个人信息被泄露。

很早之前，CSDN遭遇了SQL注入，导致了600多万条明文保存的用户信息被泄。

因此，我们在做系统设计的时候，要考虑要把用户的隐私信息加密保存。

常见的对称加密算法有 AES、SM4、ChaCha20、3DES、DES、Blowfish、IDEA、RC5、RC6、Camellia等。

目前国际主流的对称加密算法是AES，国内主推的则是SM4。

无论是用哪种算法，加密前的字符串，和加密后的字符串，差别还是比较大的。

比如加密前的字符串：苏三说技术，使用密钥：123，生成加密后的字符串为：U2FsdGVkX1+q7g9npbydGL1HXzaZZ6uYYtXyug83jHA=。

如何对加密后的字符串做模糊查询呢？

比如：假设查询苏三关键字，加密后的字符串是：U2FsdGVkX19eCv+xt2WkQb5auYo0ckyw。

前言

我之前在一家餐饮公司待过两年，每天中午和晚上用餐高峰期，系统的并发量不容小觑。 为了保险起见，公司规定各部门都要在吃饭的时间轮流值班，防止出现线上问题时能够及时处理。

我当时在后厨显示系统团队，该系统属于订单的下游业务。

用户点完菜下单后，订单系统会通过发kafka消息给我们系统，系统读取消息后，做业务逻辑处理，持久化订单和菜品数据，然后展示到划菜客户端。

这样厨师就知道哪个订单要做哪些菜，有些菜做好了，就可以通过该系统出菜。系统自动通知服务员上菜，如果服务员上完菜，修改菜品上菜状态，用户就知道哪些菜已经上了，哪些还没有上。这个系统可以大大提高后厨到用户的效率。

这一切的关键是消息中间件：kafka，如果它出现问题，将会直接影响到后厨显示系统的用户功能使用。

这篇文章跟大家一起聊聊，我们当时出现过的消息积压问题，希望对你会有所帮助。

前言

我之前在一家餐饮公司待过两年，每天中午和晚上用餐高峰期，系统的并发量不容小觑。 为了保险起见，公司规定各部门都要在吃饭的时间轮流值班，防止出现线上问题时能够及时处理。

我当时在后厨显示系统团队，该系统属于订单的下游业务。

用户点完菜下单后，订单系统会通过发kafka消息给我们系统，系统读取消息后，做业务逻辑处理，持久化订单和菜品数据，然后展示到划菜客户端。

这样厨师就知道哪个订单要做哪些菜，有些菜做好了，就可以通过该系统出菜。系统自动通知服务员上菜，如果服务员上完菜，修改菜品上菜状态，用户就知道哪些菜已经上了，哪些还没有上。这个系统可以大大提高后厨到用户的效率。

这一切的关键是消息中间件：kafka，如果它出现问题，将会直接影响到后厨显示系统的用户功能使用。

这篇文章跟大家一起聊聊，我们当时出现过的消息积压问题，希望对你会有所帮助。

前言

我之前在一家从事餐饮行业的公司待过两年，当时使用了两年的消息中间件。

最开始使用activeMQ，后面改成了rabbitMQ，再后来改成了kafka。

当时的RocketMQ并不流行，kafka的性能是非常好的。

其实这些消息中间件的思想都差不多。

我们的划菜系统是订单的下游系统。

用户下单或者有订单的状态修改，订单系统都会给我们发生mq消息，我们系统接收到消息之后，做业务逻辑处理。

今天这篇文章，跟大家一起聊聊，我们当时遇到过的消息顺序问题，希望对你会有所帮助。

前言

之前MQ带来的一些问题，我已经分享了很多了，比如：消息顺序问题、消息积压问题、消息丢失问题等等。

今天接着MQ带来的问题这个话题，专门跟大家一起聊聊MQ消息重复消费的问题。

前言

上个月，我们有个电商系统出了个灵异事件：用户支付成功了，但订单状态死活不改成“已发货”。

折腾了半天才定位到问题：订单服务的MQ消息，像人间蒸发一样消失了。

这个Bug让我明白：（MQ）消息队列的数据一致性设计，绝对能排进分布式系统三大噩梦之一！

今天这篇文章跟大家一起聊聊，MQ如何保证数据一致性？希望对你会有所帮助。

前言

说到MySQL数据库主从延迟问题，我还是深有体会的，因为我之前经常遇到。

我之前在一家餐饮工作公司中，当时我们的系统属于订单的下游业务系统。

在中午和晚上的用餐高峰期，用户并发量还是不小的。订单系统为了保证性能和高可用，做了主从分离架构。

一个主库，两个从库。

主库主要用来写数据，从库主要是用来读数据，主库的数据会实时同步到从库。

但偶尔会出现主从延迟问题。

前言

在电商、外卖、票务等系统中，订单超时未支付自动取消是一个常见的需求。

这个功能乍一看很简单，甚至很多初学者会觉得："不就是加个定时器么？" 但真到了实际工作中，细节的复杂程度往往会超乎预期。

这里我们从基础到高级，逐步分析各种实现方案，最后分享一些在生产中常见的优化技巧，希望对你会有所帮助。