一种介于待办和通知的需求有没有好的思路？

[shyrock]

公司的 erp 软件，每个不同的角色有自己的不同的待办事项。 根据其人所属项目、所属部门、所属角色需要推送不同的待办通知给他。

目前的实现有两个思路，一是点击后根据这个人的各项属性查询数据，并过滤出需要他处理的事项。这个的问题是性能太低，点了之后要查一分钟才能看到所有待办。 二是后台监控内容变更，当满足某人的条件时，推送一条消息给他。客户端只需要列出该人的所有待办消息即可，性能很高。缺点是在其他终端处理了事项时没有办法消除所有终端的通知，需要人工点击完成待办。

这两种方案似乎是优劣互补的，但是我没有好得思路能结合到一起。 不知各位大佬有没有更好的思路？

[libook]

性能差可以优化性能，这个具体得看你业务和系统架构怎么设计的，比如数据库索引是否有优化空间，是否需要添加 ES 之类的搜索引擎，是否可以预处理、是否需要用缓存。
下发通知可以在完成之后再下发一条完成的通知，客户端可以根据唯一标识来匹配要把哪条信息自动标为已读。

[Saxton]

@shyrock 按照你的业务需求来，如果你待办上有比较特殊字段的需求，那就必须侵入业务逻辑，肯定需要第二个方案，同步插入一条待办这没什么，代码尽量轻一些去侵入，但通知这个可以外置。
如果你的待办很简单粗暴，那我可以第一个来去外置，但定时轮训这个有点太骚了
其实可以考虑下消息队列 mq ，把新增行为推送到队列，然后去异步消费就行了。

通知和待办这东西 本身就是两个东西，不用太纠结。

[Saxton]

@shyrock 不用太纠结啦，如果系统是屎山，多堆点屎上去也是没有办法的事， 如果你想着优化，可以考虑下我说的方案。

[shyrock]

@libook #21 我感觉优化很难，因为一个用户可能有数十种待办，每种待办意味着一套独立的查询。针对每个查询可以优化，但是投入和产出不成正比。

[Saxton]

@shyrock 数 10 分，不应该都是同一个表吗 难不成一种待办一个表？

[libook]

@shyrock #24 那得看这算不算技术债务了，短期投入产出比低的话对长期发展是否有影响，比如业务和代码越滚越多之后，是不是总会不得不去解决这个问题，是的话就说明这个是必要成本，只不过现在用了简单方案欠了债而已。

[shyrock]

@Saxton #22 归根结底待办是业务逻辑的延申，随业务逻辑的变更而变。
如果一开始业务逻辑就抽象了业务和待办的关系--比如用工作流引擎和事务来封装业务逻辑，
那么待办逻辑也可以聚焦起来。
现在在屎山里面抽丝剥茧新增待办逻辑确实很难优雅。

[shyrock]

@Saxton #25 每一种业务有不同的表，对吧？现在要把所有业务的待办列到一个待办列表里，中间必然有一个步骤是查询多种业务表，然后生成待办。可以选择在客户点开待办的时候去查，也可以先在后台查好在推送到前端。

[shyrock]

@libook #26 如果是历史债务，越换越少还好。我认为这个是架构没有匹配待办这个业务，意味着每一个新增的流程都会需要考虑怎么加入待办，以及怎么优化待办性能。这种情况，我认为优化单个待办的性能就是个无底洞一样的任务了。

[murmur]

点了之后要查一分钟才能看到所有待办，你们待办接口太菜，待办是有独立表的，查个数据就算 filter ，这不管推送的事

我们的推送也是轮训，而且轮训十多个系统，也没见哪个接口菜到一分钟才返回

[kop1989smurf]

简单说其实就是实现抢单模式。

1 、这个单子到底谁能看到，是单据创建时候决定的，而不是查询的时候再去过滤。
2 、每个人的单子看似内容相同，实则只是公用一个单头或者说模板，技术上的唯一单号不同。（解决了浏览速度慢的问题）
3 、有一个人抢单时，把所有共用单头的子单状态更改。（实现了多人的状态同步）

[ayase252]

@Saxton

[ayase252]

错误操作了 sorry

[Saxton]

@shyrock 不想改代码或者侵入业务逻辑，我那个方案已经是最好的选择了。

[Saxton]

@ayase252 没事亲，下辈子注意点（ doge

[shyrock]

@murmur #30 一分钟是最坏的情况，比如管理员登陆，有上百个待办列表要刷新。重点在于每个待办并不是提前筛选到待办表的，而是要根据业务逻辑一个一个查出来。

如果有待办表，那么问题就转化为怎么来更新这个待办表。

[wolfie]

待办任务、消息通知。

首先，为什么查询一个人所有的待办会很慢？

消息通知，入库时候可以标记为 『暂存状态』，由用户查询时检查，哪些『暂存状态』消息 关联的任务已经完成。

[shyrock]

@kop1989smurf #31 某些部分是类似抢单的，不过抢单我理解是单一任务类型，但是推送大量用户；我这个是反过来用户不多，但是任务类型很多，所以过滤并更新任务表是个核心问题。

[shyrock]

@wolfie #37 因为数据是围绕业务单据组织的，比如一个项目审核，需要 10 个角色参加，查询的时候是先筛选出符合条件的项目，再根据项目负责人和参与人找到需要推送的评审对象。这个过程不是查一张表那么简单和快速。

[kop1989smurf]

@shyrock #38 所以才是发布任务时过滤。也就是说发布任务时一次性过滤这个单子谁能看，谁不能看，然后创建 n 个子单，分发给 n 个人。同步的时候根据相同的单头来同步状态。