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

第一个方案有问，为什么要根据这个人各项属性查询数据？难道生成的这条待办没有归属人吗，还是说大家都可以处理掉这个待办
第二个方案也有问，"缺点是在其他终端处理了事项时没有办法消除所有终端的通知" ， 这个不是很正常吗， 通知这个东西一旦下发就很难做撤回的操作了。

待办事项的推送这块我也做过，不过场景没楼主这么复杂，都是一定条件后会触发一条系统内的消息和系统外的消息推送，条件的监控是监听数据库的 binlog 日志来做的，完全解耦并独立于系统外的，我的设计方式是设计好一套规则，如果监听到的数据行为符合这个规则就生成一条待办并完成推送，规则这块我设计了一个规则模板引擎，让运营在后台自己设置。

但我这个解析 binlog 的方式也有一定局限，在操作上有一定受限，毕竟是完全解耦独立的， 无法参与到业务逻辑中， 就看你需求了。

@Saxton #1 有的待办有明确归属人，有的待办可以有多个人可以处理。

@Saxton #2 似乎你的方法也只能手动点击完成待办，对吧？

告警

@gainsurier #5 ？？

手动点击完成待办？ 我们没有这个需求， 所有待办自动完成的， 触发规则就完成他， 比如 小明今天新增了一个合同信息，但合同还没签约， 这个时候就会新增一条合同签约待办给小明， 但如果当合同的状态变更为签约， 这个待办自动完成。 我设计的规则模板可以指定待办触发条件和完成条件

@shyrock

@Saxton #7 明白了，就是跟触发通知一样的逻辑，后台监控发现完成了就消除通知？

@shyrock 是的 不能说消除通知吧 ，通知这个东西一旦下发下去， 什么状态就什么状态， 而且通知一旦下发下去，你去手动消除他反而更不符合业务需求，用户明明收到他通知了，但被你删了，等到他看却发现没有，这个行为就很奇怪了。
待办会被变更为已完成。

@Saxton #10 意思是看通知，待办数量是 1 ，点进去看待办数量是 0 ？（因为已经后台监控修改了待办状态）

为啥，不两个都用。

第一个思路不用于通知，而是用于个人收到通知后（或者随时）的主动查询。这是类似于“我的……”的功能，有没有通知都要做。

第二个思路，去掉“完成待办”操作，增加“已读”操作，如果有闲工夫，还可以增加跨终端消息已读状态同步功能，再有闲功夫，还可以增加“之前你的某某任务已被他人处理”提醒消息。

通知 /推送的主体是系统，待办任务的主体是个人，这俩是两码事，要分开处理，合在一起就会引起混乱。在细分一点，通知消息的生成跟读取也要分开，前者主体是系统，后者主体是个人。

@shyrock 像你所说的，一条待办可以很多人处理，那就肯定会下发通知给多个人， 其中一个人完成其他人的通知还存在，这个行为很正常，你想想，一个人收到一条待办消息，暂时没空处理，另外一个人正好有空给他处理了，但第一个人要处理的时候发现通知怎么没了， 就很奇怪了，正常的逻辑是第一个人想要处理点通知进去发现已经被处理了就不处理了，这个逻辑很正常，但有些产品设计时会考虑到用户对通知的反感度， 太多的消息反而都不用处理就会引起用户的不满，就看产品怎么说了。

通过在通知消息中附加待办的处理入口，让用户可以从消息直接导航到相关任务，这样可以提高用户的效率。但是这是““我的……””功能的辅助，不是替代就是别用“我的未读消息”来代替“我的……”

@shyrock 其实不用在这纠结这个 01 问题，这个是产品该纠结的问题，产品如果需要那肯定就是需要，除非你就是产品。

@nothingistrue #12 问题在于主动查询太慢了，有些岗位十多二十个待办种类，每一个都即时查询很花时间。

@shyrock 主动查询太慢，我有点不是很理解，待办这种东西不应该是生成一条记录然后给到归属用户嘛，就算归属多人一样可以再字段上体现，查的时候只需查待办表就行了。

@nothingistrue #14 确实也是从消息导航到处理界面。重点还是第一个问题，每次即时查询待办太慢，所以才想是否可以用通知代替即时查询。。。

@Saxton #17 你说的这个方法就不是点击时主动查询了，实际上是后台查出来后更新到一个待办表，问题在于待办表什么时候插入记录？这里有两个选择：一是定时轮询，好处是可以外挂逻辑，不用侵入到业务代码。缺点是要为每个人的每种待办查询，速度是个问题 i ；
二是在业务逻辑中判断并插入到待办，缺点是侵入了业务代码，要改的地方很多很分散。。。

@Saxton #15 也算产品吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Saxton

错误操作了 sorry

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

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

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

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

待办任务、消息通知。

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

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

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

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

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

@kop1989smurf #40 这个接近于我说的第二个方案。处理完待办后怎么-1 呢？

@shyrock #41 完成待办后肯定你这个人有某个子单，然后根据子单上的单头号，给剩下的其他子单置状态即可。

@shyrock
查询速度慢，还是设计的问题。

待办任务表结构（参考 Activiti ）：待办任务、待办任务_角色关联、待办任务_用户关联。

@shyrock
建议把涉及的表结构列出来，大家好评估优化。

有点像 flowable 的待签事务，待签事务在 flowable 中需要手动签收后转入待办再处理（相当于签收）。这个查询是基于组和用户来实现的，查询前先查出用户所有的组然后再去查询这些组对应的待签事务

@wolfie #43 谢谢你的热心回复。不过现在其实没有已经建好的待办表。实际的表格例如 [项目表] ：项目内容字段、商务评审人、财务评审人、风控评审人、技术评审人 1 、技术评审人 2 、技术评审人 3 、项目进度、项目毛利。
要求是项目如果毛利低于 30%需要加入风控评审和技术评审人 3 ；如果项目涉及到定制开发，需要技术评审人 2 和技术评审人三；商务评审人只评审他自己的项目以及他下属的项目。

这样的要求涉及到其他类似的几十个单据表格。

@buliugu #45 差不多，我也是通过用户所属的角色组来查询的，但是每种事务有独特的查询规则。签收这个操作没看出来能改善哪方面。。。

待办的放待办 ，通知加个已读未读标签不就可以了

@carrie96 #48 不是已读就 OK ，需要的是已经处理了才 OK 。

@shyrock 通知不就是抄送 审批完成之类的吗 需要处理的话就是待办了

@carrie96 #50 本质是待办，我只是在想是不是能借用通知来实现。

@shyrock
不想弄待办，但要新增 『通知功能』，类似待办。

> 缺点是在其他终端处理了事项时没有办法消除所有终端的通知

这个通知加一个 随机批次号，完成任务后删除相同批次通知。

@shyrock 那就更应该考虑解耦的方案了，毕竟都有几十个单据表格了，再有新增也不奇怪，侵入业务的方式不可持续。在变更事件发生时去 创建 /更新 “待办”（或者这里更像一个工作流？），创建时再根据业务资源（不同的策略）筛选出参与人并绑定。

这样的话，“待办” 就独立了，再去做待办的各种接口也比较方便。

没有仔细看，个人觉得： “抢单”就是和业务逻辑有关系了，这种单独设计；其它通知类的都分配给每个具体的人，每个人只查询自己的

@shyrock 签收是确定处理人并减少代签的数量