耗时的工作交给谁？

weixin_36299249 2016-10-27 09:17:12

我们是一个电商平台，先来描述一下业务逻辑。
用户确认收货时，我们后台要查询这个用户的推荐人（向上递归），可能有N个，是的，就是N个！
现在问题来了，不可能在用户点击确认收货后，我们要让客户等个1分钟或者N分钟吧？
请问有什么好思路呢？
之前想过异步，队列。

关键是：用户确认收货后，用户的推荐人们能在1~10分钟能收到奖励（当前秒到最好）

...全文

2502 34 打赏收藏转发到动态举报

写回复

34 条回复

切换为时间正序

请发表友善的回复…

发表回复

左耳听风 2018-06-25

打赏
举报

回复

兄die把分给我

左耳听风 2018-06-25

打赏
举报

回复

用什么异步？线程？redis?
在数据库设计的时候就应该考虑好这么问题怎么解决了，正常用户表要记录一个字段parent_node_path（父节点路径，以逗号分隔）！！这样查询不是很快么，以空间换时间。

幽饮烛 2018-06-21

打赏
举报

回复

微信公众号是不允许超过2级分销的，这种多级返利，基本上可以断定是传销了。

这种情况一个后台异步任务就搞定了。

weixin_40852944 2018-06-21

打赏
举报

回复

确认收货以后，交给后台任务去做就行了

hash_boy1 2018-06-21

打赏
举报

回复

用消息队列解耦好一点吧，另外oracle 的start with ,connect by 可以直接实现递归查询。

u014518951 2018-05-16

打赏
举报

回复

开一个线程把递归出来的人和奖励数额push进redis 开多个线程从redis中pull出人和奖励数额,存数据库基本上就是秒级别的.

yokey1219 2018-05-02

打赏
举报

回复

根据业务来设计，如果用户量不大，推荐人列表不长，同步来一般不会很慢。如果用户量大，交易量大，推荐人列表长，建议用消息队列异步处理。从业务角度来看，这种奖励政策是可变的，也不是事务性的，应该和用户的正常交易隔离，不应该影响当前用户的交易，只要保证交易成功的情况下，最终推荐人收到奖励就可以。而且以现在消息队列的并发能力，秒级不是问题，消费者端多跑几个线程并行去处理就行了。

水桥舞 2018-05-02

打赏
举报

回复

推荐人最多两级吧？超过两级就算传销就是违法的了，你们公司没有法务的吗？不违法的话这个做起来应该不会有时效问题

blackant2 2017-01-14

打赏
举报

回复

耗时的工作交给其它人,不应该在一次请求中处理.因为你无法确定上限. 比如发消息到kafka rocketmq 交给后面人的去处理逻辑.再复杂也没关系了.反正任务到这儿已经结束了

什么都不能 2017-01-13

打赏
举报

回复

在用户收货之前就可以将N级推荐人算好，为什么非要等收货的时候才算呢？

ryuugu_rena 2017-01-11

打赏
举报

回复

坑定要异步处理，这还用想吗？

菜鸟面条 2016-12-22

打赏
举报

回复

感觉用异步，队列蛮好的

yangjuanli 2016-12-20

打赏
举报

回复

不是2级，是超过3级就是传销。。。

ljlx 2016-12-19

打赏
举报

回复

电商应该有redis吧？，有这个的话因该就好搞了啊

dl510403557 2016-12-19

打赏
举报

回复

从业务上来说，最多2级，否则就是传销

阿麦 2016-12-16

打赏
举报

回复

这叫“血缘关系” 让推荐人等吧，客户一等就可能跑了。异步，先留住客户

酱油男js 2016-12-15

打赏
举报

回复

购买人和推荐人群是动态的新增模型，这里需要在程序设计的时候考虑好这一点，维护好一个这样的关系。每次新增一个推荐人，肯定是后台异步去更新这个用户关系。等你最后用户收货的时候，再来批量更新就不难了。异步是肯定的，是否缓存，放哪里，有待分析考证

jackson__qi 2016-12-07

打赏
举报

回复

搞一个消息系统来解耦合吧

什么都不能 2016-12-07

打赏
举报

回复

这是传销吗？

月明星稀灬 2016-12-05

打赏
举报

回复

个人决定，可以把推荐人组合成一个字段，存入那个订单信息表字段中，查的时候直接当场就解析了。 name：推荐人1,推荐人2,推荐人3,推荐人4... 解析的时候就字符串解析咯。

加载更多回复（13）

本课程基于最新版开源工作流Flowable 6.6.0进行讲解。着重讲解Flowable工作流的概念、理论和实战。课程内容包括Flowable的架构、安装部署与配置、工作流应用开发与运行的主要过程、Flowable流程引擎服务及其API、Flowable主要元素如事件/序列流/网关/活动和任务、Flowable表单引擎的安装配置和引擎服务、Flowable表单引擎与Spring的集成、表单定义及部署、表单REST API、 Flowable 身份管理应用、Flowable 建模器应用、Flowable 任务应用和Flowable 管理应用等概念、术语和实战内容，让大家能快速实现基于Flowable的流程应用开发。通过对Flowable官方文档进行了彻底梳理和融汇贯通，并结合实践，整合成13小时15分钟共56节的基础课程，系统、简明地呈现给大家，让大家从开源软件文档冗长耗时、英文晦涩难懂、概念理解困难的困境中解脱出来，从而能快速地将Flowable应用到项目实践中去。课程特色：案例和代码驱动、概念与实战相结合。

大家对多线程处理耗时工作的重要性应该早已认识到。本章的关键点是：把耗时的、与UI渲染无关的操作进行分割分配到多个线程中并发执行。在本章，googler 全篇介绍了通过 java 线程池来构造多线程执行环境的详细流程，关键要点如下： 1. 定义一个能在 Thread 中执行的 Runnable 子类 SubRunnable，把耗时的工作交给 SubRunnable

一、BroadcastReceiver 注册方式 BroadcastReceiver 有两种注册方式，一是使用 { Context.registerReceiver()} 动态注册，另一种是在 AndroidManifest.xml中通过元素静态注册。 Note：如果你在Activity的 onResume() 方法中注册广播，就需要在 onPause()方法中取

Android规定，访问UI只能在主线程中进行，若在子线程中进行UI访问，就会抛出异常。 Q:系统为何要求不能在子线程中访问UI？ A:Android的UI控件不是线程安全的，多线程并发的访问，可能造成UI控件不可预期的状态。 Q:为何系统不对UI控件的访问加上锁机制呢？这样就可以多线程并发访问了。 A:1.加上锁机制后，会使UI控件的访问逻辑变复杂；2.加锁之后，UI访问效率变低，因为锁...

使用springaop实现自定义注解统计方法耗时

高性能WEB开发

25,985

社区成员

4,366

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章