年底了大家都要述职，老板都会问：你这个方案，是否沉淀形成一套可复用解决方案？ 今天就介绍关于一个业务：状态变多、条件分支增多、状态转换规则、依赖关系变复杂，导致代码难以维护，代码可重用性和可扩展性变差

前言 接口性能问题，对于从事后端开发的同学来说，是一个绕不开的话题。想要优化一个接口的性能，需要从多个方面着手。 其实，我之前也写过一篇接口性能优化相关的文章《聊聊接口性能优化的11个小技巧》，发表之

想知道2017年至2022年，与日常购物息息相关的好用功能是如何逐步迭代上线的吗？请看此文（长文预警）

🌈🌈🌈🌈🌈🌈🌈🌈 欢迎关注公众号（通过文章导读关注），发送笔记可领取 Redis、JVM 等系列完整 pdf！ 【11来了】文章导读地址：点击查看文章导读！ 🍁🍁🍁🍁🍁🍁🍁🍁 初版营销系统设计方案 对

大家好，我是哪吒。 我第一次接触缓存的时候，是用map做的，当时做一个实时数据同步的功能。 需求看似简单，一取一传 当时是通过websocket获取服务端数据； 然后根据数据类别，将数据缓存到本地ma

需求： 用户通过签到、活动、下单等渠道获取积分，积分30天后过期(可配置)。用户下单可以使用积分抵扣金额，优先使用快过期的积分，但当订单取消后，积分也要原路退回。

目前我们 Google 订阅支付功能已经上线几个月，随着优化以及修改BUG，渐渐的趋于稳定了，所以这时候来总结一下，我遇到的坑。 回顾一下，之前的一篇文章：Google 支付订阅商品服务端设计方案 遇