简介用户激励体系是提升产品活跃度与留存的核心策略其原理在于通过任务、积分、游戏化等机制正向引导用户行为创造持续互动循环。在技术实现上需构建稳定高效的经济系统与状态管理。Spring Boot 作为成熟的Java框架提供了快速构建复杂业务系统的能力而 Redis 凭借其高性能与原子操作特性成为应对高并发场景如积分兑换、抽奖的关键组件。两者的结合能有效支撑用户激励系统中资产状态管理、实时库存控制、分布式锁等核心需求。本文以“牧场养牛”这一具体模型为例深入拆解如何运用 Spring Boot 与 Redis 实现包含成长任务、积分商城、大转盘及会员体系的完整激励闭环为电商、社区等场景的用户运营提供可直接复用的工程实践方案。1. 项目概述一个“好玩”又能“赚钱”的牧场养牛系统最近在捣鼓一个挺有意思的项目一个融合了牧场养牛、积分商城、大转盘抽奖和会员特权的综合系统。这玩意儿听起来像是个游戏但实际上它的应用场景远比游戏广泛。你可以把它看作一个“用户成长与互动激励平台”的实体化模型。核心逻辑很简单用户通过模拟“养牛”这一核心行为签到、做任务、参与互动等来获取虚拟资产牛、饲料、金币这些资产可以兑换积分积分又能去商城消费或者参与大转盘抽奖而会员则享有加速成长、专属商品等特权。这本质上是一套设计精巧的用户留存、活跃与转化模型常见于电商、社区、工具类应用甚至是线下实体店的会员运营中。我之所以花时间亲测并拆解这套系统是因为它麻雀虽小五脏俱全。它把用户生命周期管理中的几个关键环节——任务体系养牛、积分体系产出与消耗、游戏化互动大转盘、分层运营会员特权——用一条清晰的逻辑链串了起来。对于想了解如何构建用户激励体系的产品经理、运营或是想学习如何实现这类多模块耦合系统的开发者来说这都是一个绝佳的练手和分析案例。它不涉及过于复杂的算法但非常考验你对业务逻辑的理解和模块化设计能力。接下来我就把自己从零搭建、测试到优化这套系统的全过程、核心设计思路、踩过的坑以及一些能直接“抄作业”的代码片段分享出来。2. 系统核心架构与设计思路拆解2.1 业务逻辑闭环设计这个系统的魅力在于它形成了一个自洽的“生产-积累-消耗-激励”闭环。我们首先得把这个闭环画明白后面的技术实现才有方向。核心闭环如下行为触发生产养牛用户完成指定行为如每日登录、阅读文章、分享内容系统视为“喂养”或“获得”一头牛。这里的“牛”是核心虚拟资产是价值的载体。资产产生收益挤奶/成长牛不是静态的它需要定时“挤奶”来产出“牛奶”即积分或者经过一段时间“成长”后价值提升。这引入了时间维度和用户活跃要求。积分流通与消耗商城/抽奖产出的“牛奶”积分可以在积分商城兑换实物或虚拟商品也可以用于大转盘抽奖以小博大的心理能极大刺激积分消耗。特权加速循环会员体系会员用户享有特权例如养牛速度翻倍、每日可挤奶次数增加、商城专属折扣、大转盘中奖概率提升等。特权系统为闭环注入付费点或高价值用户激励加速整个循环。设计这个闭环时关键要考虑经济系统的平衡性。比如一头牛每天产出的积分上限、商城商品所需的积分定价、大转盘奖品的价值和概率、会员特权的强度这些数值需要反复测试调整避免出现积分通货膨胀积分不值钱或通货紧缩积分太难获取用户失去动力。我的经验是先设定一个核心锚点例如“一个活跃用户每天大约能获得100积分”然后以此推算其他参数。2.2 技术架构选型考量对于这样一个包含前后台、有状态更新牛的生长、积分变化、有定时任务挤奶重置、有高并发潜在风险大转盘抽奖的系统技术选型需要稳健。后端我选择了Spring Boot。理由很直接生态成熟能快速集成数据库、缓存、消息队列、定时任务等几乎所有需要的组件。特别是对于业务逻辑复杂的系统Spring 的 IOC 和 AOP 特性能让代码结构更清晰。数据库主库使用MySQL存储用户信息、牛只数据、积分流水、商品信息、订单记录等需要持久化且关系复杂的数据。考虑到“大转盘抽奖”这类高频读写的场景必须引入Redis作为缓存和计数器。例如抽奖的奖品库存、用户当日抽奖次数都必须用 Redis 的原子操作如DECR、INCR来保证在高并发下的准确性和性能。定时任务牛的成长状态更新、每日挤奶次数重置这类需要准时执行的任务我用了Spring Scheduler配合 Cron 表达式。对于更复杂、需要分布式协调的任务可以考虑XXL-JOB或Quartz。前端考虑到快速原型和丰富的交互效果如转盘动画我使用了Vue 3Element Plus。对于养牛这种需要动态展示牛的生长动画的页面Vue 的响应式数据和组件化开发非常高效。注意千万不要把所有业务逻辑都堆在数据库里用 SQL 或存储过程解决。尤其是积分增减、抽奖这类操作一定要在应用层用事务包裹并配合 Redis 锁或乐观锁机制防止超卖、积分不一致等问题。3. 核心模块详细实现与避坑指南3.1 牧场养牛模块资产与状态管理这是系统的基石核心是“牛”这个实体对象的设计。数据表设计关键字段CREATE TABLE user_cattle ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, cattle_no varchar(32) NOT NULL COMMENT 牛只唯一编号, cattle_type tinyint(4) NOT NULL COMMENT 牛品种1普通2稀有, growth_stage tinyint(4) DEFAULT 1 COMMENT 生长阶段1幼崽2成长3成年, growth_value int(11) DEFAULT 0 COMMENT 成长值, milk_available int(11) DEFAULT 0 COMMENT 当前可挤奶量积分, last_milk_time datetime DEFAULT NULL COMMENT 上次挤奶时间, daily_milk_count tinyint(4) DEFAULT 0 COMMENT 今日已挤奶次数, status tinyint(4) DEFAULT 1 COMMENT 状态1正常2生病3收获, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB COMMENT用户牛只表;核心逻辑实现成长系统通过一个每日定时任务扫描所有status1的牛为其增加growth_value。当成长值达到阈值更新growth_stage。不同阶段的牛产奶效率不同。产奶积分产出系统产出计算可挤奶量milk_available根据牛的类型、生长阶段和健康状态按公式计算例如基础产出 * 阶段系数 * 健康系数。会员特权可能在这里乘以一个系数。挤奶操作这是关键接口。用户点击“挤奶”时后端需要 a. 检查daily_milk_count是否超过每日上限会员上限更高。 b. 检查last_milk_time是否满足最小间隔如间隔6小时。 c. 在事务中将milk_available累加到用户积分总账生成一条积分收入流水重置milk_available为0或按规则留底更新last_milk_time和daily_milk_count。踩坑实录这里最容易出现并发问题。两个请求同时为同一用户挤奶可能导致积分重复增加。解决方案是使用SELECT ... FOR UPDATE行锁或者更优雅地用user_id作为Key的分布式锁Redis实现在锁内执行整个检查更新的逻辑。3.2 积分商城模块交易与库存管控积分商城是积分消耗的核心出口设计要点是商品管理和订单防刷。商品设计商品分为实物需要发货和虚拟如优惠券、卡密。表设计需包含商品类型、所需积分、库存实物库存和虚拟库存可能分开、每人限购数量、上下架状态。兑换流程预检查校验商品状态、用户积分是否足够、是否达到个人限购。扣减库存与积分核心事务Transactional(rollbackFor Exception.class) public ExchangeResult exchange(Long userId, Long itemId) { // 1. 查询商品带悲观锁或使用乐观锁版本号 Goods goods goodsMapper.selectForUpdate(itemId); // 2. 检查所有条件库存、积分、限购 // 3. 扣减商品库存goods.setStock(goods.getStock() - 1) // 4. 扣减用户积分userPointMapper.decreasePoint(userId, goods.getPointCost) // 5. 生成订单记录 // 6. 记录积分消耗流水 // 如果任何一步失败事务回滚 }后续处理根据商品类型走不同的履约流程。虚拟商品直接发放并更新状态实物商品生成发货单进入物流流程。实操心得对于高热度商品上述流程在并发下数据库压力巨大。我的优化方案是前置库存校验到 Redis。在商品发布时将库存数量加载到 Redis。用户点击兑换时先使用Redis.decr原子操作预扣 Redis 库存如果结果0才进入上述数据库事务流程。事务成功后再异步同步 Redis 库存与数据库库存。即使事务失败也需要将 Redis 库存加回去或通过后台任务校准。这相当于用 Redis 承担了大部分并发请求的过滤。3.3 大转盘抽奖模块概率、并发与风控这是系统中最“刺激”也最容易出问题的模块。奖品池设计奖品配置表应包含奖品ID、名称、类型实物/虚拟/谢谢参与、库存、概率单位可以是万分之几、每日发放上限等。概率不建议在代码中写死最好配置在数据库或配置中心方便运营调整。抽奖算法实现别名算法这是保证概率准确的关键。不要用简单的Math.random()。public Prize drawLottery(ListPrize prizePool) { // 1. 计算总概率区间 double totalWeight prizePool.stream().mapToDouble(Prize::getWeight).sum(); // 2. 在总区间内随机一个数 double random Math.random() * totalWeight; // 3. 遍历奖品用随机数递减权重减到0即为中奖 for (Prize prize : prizePool) { random - prize.getWeight(); if (random 0) { return prize; } } // 理论上不会走到这里 return getDefaultPrize(); }高并发抽奖的“三把锁”用户频率锁用Redis.setnx(“lottery:user:limit:”userId“:”today, 1, 24h)控制用户每日抽奖次数。setnx的原子性保证了并发下的准确性。奖品库存锁和商城类似用Redis.decr(“lottery:prize:stock:”prizeId)原子预扣库存。这是防止奖品超发的生命线。全局活动锁对于极端热点活动可以在入口处用 Redis 做简单的令牌桶限流防止系统被瞬间击垮。抽奖结果处理抽中后异步写入中奖记录表并触发后续的奖品发放流程如发放积分、优惠券或生成实物兑换订单。一定要给用户即时的“中奖”视觉反馈后台异步处理偶尔的延迟用户是可以接受的。3.4 会员特权模块分层权益与升级体系会员系统不是简单的布尔标签而是一套权益包。设计要点等级体系可以设计为成长值等级如V1-V5成长值通过养牛、签到、消费等行为获取。权益配置化将每一项权益如“养牛收益20%”、“每日免费抽奖1次”、“商城9.5折”作为可配置项与会员等级关联。这样运营可以灵活调整。权益生效机制不要在每次业务逻辑里都去查用户等级和权益列表然后计算。这样性能差。我的做法是 a. 用户等级或权益变更时计算出一个“权益快照”或“权益系数”存入 Redis。例如user:privilege:1001 - {“milkRate”: 1.2, “freeLottery”: 1, “discount”: 0.95}。 b. 在养牛计算产出、检查抽奖次数、计算商品价格时直接从 Redis 获取这些系数进行运算性能极高。会员升级通知当用户升级时通过站内信、App Push 等方式及时通知并清晰告知新解锁的特权这能带来强烈的正向反馈和激励。4. 数据库设计与性能优化实战4.1 核心表结构关系图一个清晰的ER关系图是理解的开始。核心实体包括用户、牛只、积分账户、积分流水、商品、订单、抽奖奖品、中奖记录、会员等级、权益配置。它们之间的关系主要是一个用户拥有多只牛、一个积分账户、多条积分流水、多个订单、多条中奖记录属于一个会员等级。积分流水与订单、抽奖记录关联记录每一分积分的来龙去脉这很重要用于对账和风控。订单与商品关联。中奖记录与奖品关联。4.2 读写分离与分库分表考量随着数据量增长单一数据库会成为瓶颈。读写分离这是第一步。将积分流水查询、订单查询、用户行为日志查询这类读多写少的请求路由到只读从库。使用 Sharding-JDBC 或 MyCat# 1. 两数之和题目给定一个整数数组 nums 和一个整数目标值 target请你在该数组中找出 和为目标值 target 的那 两个 整数并返回它们的数组下标。你可以假设每种输入只会对应一个答案。但是数组中同一个元素在答案里不能重复出现。你可以按任意顺序返回答案。思路使用哈希表将数组中的元素作为key下标作为value遍历数组对于每一个元素计算target - nums[i]的值判断这个值是否在哈希表中如果在返回当前元素的下标和哈希表中对应元素的下标如果不在将当前元素和下标存入哈希表代码class Solution { public: vectorint twoSum(vectorint nums, int target) { unordered_mapint,int map;// 哈希表 key 存放元素 value 存放下标 for(int i 0; i nums.size(); i) { // 遍历当前元素并且在map中寻找是否有匹配的key auto iter map.find(target - nums[i]); if(iter ! map.end()) { // 找到了 return {iter-second,i}; } // 没有找到匹配的key 将当前元素和下标存入map map.insert(pairint,int(nums[i],i)); } return {}; } };本文还有配套的精品资源点击获取 Spring Boot + Redis 构建用户激励系统：养牛牧场实战
简介用户激励体系是提升产品活跃度与留存的核心策略其原理在于通过任务、积分、游戏化等机制正向引导用户行为创造持续互动循环。在技术实现上需构建稳定高效的经济系统与状态管理。Spring Boot 作为成熟的Java框架提供了快速构建复杂业务系统的能力而 Redis 凭借其高性能与原子操作特性成为应对高并发场景如积分兑换、抽奖的关键组件。两者的结合能有效支撑用户激励系统中资产状态管理、实时库存控制、分布式锁等核心需求。本文以“牧场养牛”这一具体模型为例深入拆解如何运用 Spring Boot 与 Redis 实现包含成长任务、积分商城、大转盘及会员体系的完整激励闭环为电商、社区等场景的用户运营提供可直接复用的工程实践方案。1. 项目概述一个“好玩”又能“赚钱”的牧场养牛系统最近在捣鼓一个挺有意思的项目一个融合了牧场养牛、积分商城、大转盘抽奖和会员特权的综合系统。这玩意儿听起来像是个游戏但实际上它的应用场景远比游戏广泛。你可以把它看作一个“用户成长与互动激励平台”的实体化模型。核心逻辑很简单用户通过模拟“养牛”这一核心行为签到、做任务、参与互动等来获取虚拟资产牛、饲料、金币这些资产可以兑换积分积分又能去商城消费或者参与大转盘抽奖而会员则享有加速成长、专属商品等特权。这本质上是一套设计精巧的用户留存、活跃与转化模型常见于电商、社区、工具类应用甚至是线下实体店的会员运营中。我之所以花时间亲测并拆解这套系统是因为它麻雀虽小五脏俱全。它把用户生命周期管理中的几个关键环节——任务体系养牛、积分体系产出与消耗、游戏化互动大转盘、分层运营会员特权——用一条清晰的逻辑链串了起来。对于想了解如何构建用户激励体系的产品经理、运营或是想学习如何实现这类多模块耦合系统的开发者来说这都是一个绝佳的练手和分析案例。它不涉及过于复杂的算法但非常考验你对业务逻辑的理解和模块化设计能力。接下来我就把自己从零搭建、测试到优化这套系统的全过程、核心设计思路、踩过的坑以及一些能直接“抄作业”的代码片段分享出来。2. 系统核心架构与设计思路拆解2.1 业务逻辑闭环设计这个系统的魅力在于它形成了一个自洽的“生产-积累-消耗-激励”闭环。我们首先得把这个闭环画明白后面的技术实现才有方向。核心闭环如下行为触发生产养牛用户完成指定行为如每日登录、阅读文章、分享内容系统视为“喂养”或“获得”一头牛。这里的“牛”是核心虚拟资产是价值的载体。资产产生收益挤奶/成长牛不是静态的它需要定时“挤奶”来产出“牛奶”即积分或者经过一段时间“成长”后价值提升。这引入了时间维度和用户活跃要求。积分流通与消耗商城/抽奖产出的“牛奶”积分可以在积分商城兑换实物或虚拟商品也可以用于大转盘抽奖以小博大的心理能极大刺激积分消耗。特权加速循环会员体系会员用户享有特权例如养牛速度翻倍、每日可挤奶次数增加、商城专属折扣、大转盘中奖概率提升等。特权系统为闭环注入付费点或高价值用户激励加速整个循环。设计这个闭环时关键要考虑经济系统的平衡性。比如一头牛每天产出的积分上限、商城商品所需的积分定价、大转盘奖品的价值和概率、会员特权的强度这些数值需要反复测试调整避免出现积分通货膨胀积分不值钱或通货紧缩积分太难获取用户失去动力。我的经验是先设定一个核心锚点例如“一个活跃用户每天大约能获得100积分”然后以此推算其他参数。2.2 技术架构选型考量对于这样一个包含前后台、有状态更新牛的生长、积分变化、有定时任务挤奶重置、有高并发潜在风险大转盘抽奖的系统技术选型需要稳健。后端我选择了Spring Boot。理由很直接生态成熟能快速集成数据库、缓存、消息队列、定时任务等几乎所有需要的组件。特别是对于业务逻辑复杂的系统Spring 的 IOC 和 AOP 特性能让代码结构更清晰。数据库主库使用MySQL存储用户信息、牛只数据、积分流水、商品信息、订单记录等需要持久化且关系复杂的数据。考虑到“大转盘抽奖”这类高频读写的场景必须引入Redis作为缓存和计数器。例如抽奖的奖品库存、用户当日抽奖次数都必须用 Redis 的原子操作如DECR、INCR来保证在高并发下的准确性和性能。定时任务牛的成长状态更新、每日挤奶次数重置这类需要准时执行的任务我用了Spring Scheduler配合 Cron 表达式。对于更复杂、需要分布式协调的任务可以考虑XXL-JOB或Quartz。前端考虑到快速原型和丰富的交互效果如转盘动画我使用了Vue 3Element Plus。对于养牛这种需要动态展示牛的生长动画的页面Vue 的响应式数据和组件化开发非常高效。注意千万不要把所有业务逻辑都堆在数据库里用 SQL 或存储过程解决。尤其是积分增减、抽奖这类操作一定要在应用层用事务包裹并配合 Redis 锁或乐观锁机制防止超卖、积分不一致等问题。3. 核心模块详细实现与避坑指南3.1 牧场养牛模块资产与状态管理这是系统的基石核心是“牛”这个实体对象的设计。数据表设计关键字段CREATE TABLE user_cattle ( id bigint(20) NOT NULL AUTO_INCREMENT, user_id bigint(20) NOT NULL COMMENT 用户ID, cattle_no varchar(32) NOT NULL COMMENT 牛只唯一编号, cattle_type tinyint(4) NOT NULL COMMENT 牛品种1普通2稀有, growth_stage tinyint(4) DEFAULT 1 COMMENT 生长阶段1幼崽2成长3成年, growth_value int(11) DEFAULT 0 COMMENT 成长值, milk_available int(11) DEFAULT 0 COMMENT 当前可挤奶量积分, last_milk_time datetime DEFAULT NULL COMMENT 上次挤奶时间, daily_milk_count tinyint(4) DEFAULT 0 COMMENT 今日已挤奶次数, status tinyint(4) DEFAULT 1 COMMENT 状态1正常2生病3收获, create_time datetime NOT NULL, PRIMARY KEY (id), KEY idx_user_id (user_id) ) ENGINEInnoDB COMMENT用户牛只表;核心逻辑实现成长系统通过一个每日定时任务扫描所有status1的牛为其增加growth_value。当成长值达到阈值更新growth_stage。不同阶段的牛产奶效率不同。产奶积分产出系统产出计算可挤奶量milk_available根据牛的类型、生长阶段和健康状态按公式计算例如基础产出 * 阶段系数 * 健康系数。会员特权可能在这里乘以一个系数。挤奶操作这是关键接口。用户点击“挤奶”时后端需要 a. 检查daily_milk_count是否超过每日上限会员上限更高。 b. 检查last_milk_time是否满足最小间隔如间隔6小时。 c. 在事务中将milk_available累加到用户积分总账生成一条积分收入流水重置milk_available为0或按规则留底更新last_milk_time和daily_milk_count。踩坑实录这里最容易出现并发问题。两个请求同时为同一用户挤奶可能导致积分重复增加。解决方案是使用SELECT ... FOR UPDATE行锁或者更优雅地用user_id作为Key的分布式锁Redis实现在锁内执行整个检查更新的逻辑。3.2 积分商城模块交易与库存管控积分商城是积分消耗的核心出口设计要点是商品管理和订单防刷。商品设计商品分为实物需要发货和虚拟如优惠券、卡密。表设计需包含商品类型、所需积分、库存实物库存和虚拟库存可能分开、每人限购数量、上下架状态。兑换流程预检查校验商品状态、用户积分是否足够、是否达到个人限购。扣减库存与积分核心事务Transactional(rollbackFor Exception.class) public ExchangeResult exchange(Long userId, Long itemId) { // 1. 查询商品带悲观锁或使用乐观锁版本号 Goods goods goodsMapper.selectForUpdate(itemId); // 2. 检查所有条件库存、积分、限购 // 3. 扣减商品库存goods.setStock(goods.getStock() - 1) // 4. 扣减用户积分userPointMapper.decreasePoint(userId, goods.getPointCost) // 5. 生成订单记录 // 6. 记录积分消耗流水 // 如果任何一步失败事务回滚 }后续处理根据商品类型走不同的履约流程。虚拟商品直接发放并更新状态实物商品生成发货单进入物流流程。实操心得对于高热度商品上述流程在并发下数据库压力巨大。我的优化方案是前置库存校验到 Redis。在商品发布时将库存数量加载到 Redis。用户点击兑换时先使用Redis.decr原子操作预扣 Redis 库存如果结果0才进入上述数据库事务流程。事务成功后再异步同步 Redis 库存与数据库库存。即使事务失败也需要将 Redis 库存加回去或通过后台任务校准。这相当于用 Redis 承担了大部分并发请求的过滤。3.3 大转盘抽奖模块概率、并发与风控这是系统中最“刺激”也最容易出问题的模块。奖品池设计奖品配置表应包含奖品ID、名称、类型实物/虚拟/谢谢参与、库存、概率单位可以是万分之几、每日发放上限等。概率不建议在代码中写死最好配置在数据库或配置中心方便运营调整。抽奖算法实现别名算法这是保证概率准确的关键。不要用简单的Math.random()。public Prize drawLottery(ListPrize prizePool) { // 1. 计算总概率区间 double totalWeight prizePool.stream().mapToDouble(Prize::getWeight).sum(); // 2. 在总区间内随机一个数 double random Math.random() * totalWeight; // 3. 遍历奖品用随机数递减权重减到0即为中奖 for (Prize prize : prizePool) { random - prize.getWeight(); if (random 0) { return prize; } } // 理论上不会走到这里 return getDefaultPrize(); }高并发抽奖的“三把锁”用户频率锁用Redis.setnx(“lottery:user:limit:”userId“:”today, 1, 24h)控制用户每日抽奖次数。setnx的原子性保证了并发下的准确性。奖品库存锁和商城类似用Redis.decr(“lottery:prize:stock:”prizeId)原子预扣库存。这是防止奖品超发的生命线。全局活动锁对于极端热点活动可以在入口处用 Redis 做简单的令牌桶限流防止系统被瞬间击垮。抽奖结果处理抽中后异步写入中奖记录表并触发后续的奖品发放流程如发放积分、优惠券或生成实物兑换订单。一定要给用户即时的“中奖”视觉反馈后台异步处理偶尔的延迟用户是可以接受的。3.4 会员特权模块分层权益与升级体系会员系统不是简单的布尔标签而是一套权益包。设计要点等级体系可以设计为成长值等级如V1-V5成长值通过养牛、签到、消费等行为获取。权益配置化将每一项权益如“养牛收益20%”、“每日免费抽奖1次”、“商城9.5折”作为可配置项与会员等级关联。这样运营可以灵活调整。权益生效机制不要在每次业务逻辑里都去查用户等级和权益列表然后计算。这样性能差。我的做法是 a. 用户等级或权益变更时计算出一个“权益快照”或“权益系数”存入 Redis。例如user:privilege:1001 - {“milkRate”: 1.2, “freeLottery”: 1, “discount”: 0.95}。 b. 在养牛计算产出、检查抽奖次数、计算商品价格时直接从 Redis 获取这些系数进行运算性能极高。会员升级通知当用户升级时通过站内信、App Push 等方式及时通知并清晰告知新解锁的特权这能带来强烈的正向反馈和激励。4. 数据库设计与性能优化实战4.1 核心表结构关系图一个清晰的ER关系图是理解的开始。核心实体包括用户、牛只、积分账户、积分流水、商品、订单、抽奖奖品、中奖记录、会员等级、权益配置。它们之间的关系主要是一个用户拥有多只牛、一个积分账户、多条积分流水、多个订单、多条中奖记录属于一个会员等级。积分流水与订单、抽奖记录关联记录每一分积分的来龙去脉这很重要用于对账和风控。订单与商品关联。中奖记录与奖品关联。4.2 读写分离与分库分表考量随着数据量增长单一数据库会成为瓶颈。读写分离这是第一步。将积分流水查询、订单查询、用户行为日志查询这类读多写少的请求路由到只读从库。使用 Sharding-JDBC 或 MyCat# 1. 两数之和题目给定一个整数数组 nums 和一个整数目标值 target请你在该数组中找出 和为目标值 target 的那 两个 整数并返回它们的数组下标。你可以假设每种输入只会对应一个答案。但是数组中同一个元素在答案里不能重复出现。你可以按任意顺序返回答案。思路使用哈希表将数组中的元素作为key下标作为value遍历数组对于每一个元素计算target - nums[i]的值判断这个值是否在哈希表中如果在返回当前元素的下标和哈希表中对应元素的下标如果不在将当前元素和下标存入哈希表代码class Solution { public: vectorint twoSum(vectorint nums, int target) { unordered_mapint,int map;// 哈希表 key 存放元素 value 存放下标 for(int i 0; i nums.size(); i) { // 遍历当前元素并且在map中寻找是否有匹配的key auto iter map.find(target - nums[i]); if(iter ! map.end()) { // 找到了 return {iter-second,i}; } // 没有找到匹配的key 将当前元素和下标存入map map.insert(pairint,int(nums[i],i)); } return {}; } };本文还有配套的精品资源点击获取