大家好！我是小米，一个爱技术、爱分享的技术宅男，今天特别高兴能和大家分享我们最近在开发中的一些心得与经验。最近，我们的运营团队提出了一个新的需求：需要新增一个用户分群的功能，并根据不同的用户分群发送小程序订阅通知。在实现这个过程中，我们遇到了不少问题，今天就来详细记录一下这些“坑”以及我们是如何解决的，希望对大家有所帮助。
需求背景我们电商平台上的用户越来越多，运营团队希望能够根据用户的不同特征进行分群，并针对不同分群用户采取不同的营销策略和活动通知。然而，我们当前的系统缺乏这样的用户分群工具，这使得精准营销变得困难。于是，我们决定开发一个新的用户分群功能，并基于此功能发送小程序订阅通知。
在开发过程中，我们遇到了如下几个主要问题：
问题1：用户分群系统数据同步我们的用户分群系统只有数据库而没有系统源码，这就导致我们需要先将用户分群的数据同步到我们的电商系统，再基于我们自己的数据库进行会员分群标签的设置。为此，我们最初的方案是通过用户微服务配置多数据源。
初步方案：多数据源配置
在初期，我们考虑使用多数据源配置来实现数据同步。上网查了一下资料，发现ShardingSphere支持多数据源的内容非常少。虽然多数据源看起来是一个可以实现的方案，但我们考虑到微服务本质上是服务拆分的理念，每一个微服务代表一种业务数据，比如用户微服务对应用户相关数据库，商品微服务对应商品相关数据库。为了避免短期内的利益而忽视长期的维护成本，我们最终决定新增一个用户分群服务，将相关业务放到聚合层来处理。
最终方案：新增用户分群服务
通过新增一个用户分群服务，我们将用户分群的数据同步到该服务中，然后再将数据传递到电商系统的用户微服务中进行分群标签的设置。这样不仅遵循了微服务的拆分原则，还能更好地维护和扩展系统。
问题2：异步化处理用户分群通知发送运营团队的需求是在运营后台配置好一个小程序模板，然后点击发送通知。如果默认对平台所有用户发送通知，那将涉及到百万级的会员。如果采取同步处理的方式，运营后台界面可能会直接卡死。
异步化处理方案
为了避免运营后台卡死，我们决定将通知发送过程异步化处理。具体的实现步骤如下：
任务创建：运营人员在后台点击发送按钮时，我们将该次点击记录为一个任务，并发送到消息队列（MQ）上。
数据查询：在用户服务中查询相关的用户数据，并将结果发送到MQ上。
通知发送：在消息服务中消费相关的数据，并调用微信小程序订阅通知接口。
这种方式将运营服务、用户服务、消息服务之间的操作进行了异步化处理，不仅提高了系统的响应速度，还避免了运营后台的卡死问题。
订单限制处理
需求中还提到，如果用户在昨日和今日的订单总数超过2笔，那么只需要发送一条记录。这一需求的处理方式如下：
任务记录：在运营后台点击时，我们将任务记录到MQ上。
数据过滤：在用户服务查询数据时，进行订单数量的过滤，只保留符合条件的用户。
去重处理：在消息服务中消费数据时，进行去重处理，确保每个用户只收到一条通知。
问题3：用户分群标签的精确查询由于每个用户可以属于多个分群标签，我们使用ElasticSearch来存储用户的信息以方便查询。在用户表中，我们用一个字段来存储用户的分群标签，存储格式为1,2,3。然而，这样的存储格式带来了一些问题。
初步方案：字符串匹配
最初，我们通过简单的字符串匹配来查询用户分群标签。例如，如果查询标签为1，那么用户标签为1,2,3和11,12,13的用户都会被查出来。这显然不是我们想要的结果。
改进方案：前后加逗号
为了实现精确查询，我们在存储标签时，在每一个标签前后加上逗号。比如，用户的分群标签为1,2,3，存储时变为,1,2,3,。查询时，标签为,1,，这样就可以做到精确匹配，避免了标签重叠带来的误差。
最终方案：精确存储与查询
最终的存储格式为,1,2,3,，查询时也是使用逗号包裹的格式,1,，通过这种方式，我们实现了精确的标签匹配，确保查询结果的准确性。
总结通过上述三个问题的解决，我们不仅完成了用户分群功能的开发，还优化了系统的性能和数据的准确性。以下是我们在实现过程中的一些经验总结：
微服务拆分：不要为了解决短期问题而牺牲系统的长期可维护性。通过合理的服务拆分，可以更好地管理和扩展系统。
异步化处理：在处理大规模数据时，异步化处理是提高系统响应速度和稳定性的有效手段。
精确查询：在进行复杂查询时，确保存储和查询方式的精确匹配，避免不必要的数据误差。
END希望我们的经验能够对大家有所帮助！如果你在开发过程中也遇到了类似的问题，欢迎在评论区与我们交流探讨。我们一起进步，一起成长！
谢谢大家的阅读，我们下次再见！
