大家好！我是小米，一个爱技术、爱分享的技术宅男，今天特别高兴能和大家分享我们最近在开发中的一些心得与经验。最近，我们的运营团队提出了一个新的需求：需要新增一个用户分群的功能，并根据不同的用户分群发送小程序订阅通知。在实现这个过程中，我们遇到了不少问题，今天就来详细记录一下这些“坑”以及我们是如何解决的，希望对大家有所帮助。

需求背景

我们电商平台上的用户越来越多，运营团队希望能够根据用户的不同特征进行分群，并针对不同分群用户采取不同的营销策略和活动通知。然而，我们当前的系统缺乏这样的用户分群工具，这使得精准营销变得困难。于是，我们决定开发一个新的用户分群功能，并基于此功能发送小程序订阅通知。

在开发过程中，我们遇到了如下几个主要问题：

问题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

希望我们的经验能够对大家有所帮助！如果你在开发过程中也遇到了类似的问题，欢迎在评论区与我们交流探讨。我们一起进步，一起成长！

谢谢大家的阅读，我们下次再见！

【更多精彩内容，欢迎关注小米的微信公众号“软件求生”】