被⾯试官问到项⽬中的难点？是时候对⾃⼰的项⽬进⾏总结了（记⼀次项⽬问题
总结）
⽂章⽬录
项⽬介绍
此项⽬提供了⼩组成员共享任务提醒的功能。
具体功能为：
管理员对任务或事件的创建，以及对任务的分配。
定时给任务执⾏⼈发送提醒。
任务执⾏⼈完成任务。
额外说明：
⼩组中最少有⼀个管理员，最多有两个管理员。
成员数量不做限制，但根据场景不建议超过10个。
除管理员外普通成员没有创建和修改任务的权限。
任务：固定时间点给执⾏⼈提醒要做的事情。
事件：所有成员都可以看到的有时间段的事件，事件本⾝不具备提醒功能，可以添加关联的任务给相应的执⾏⼈发送提醒，⽐如在事件开始的时候关联⼀个事件开始的任务，在事件结束的时候关联事件结束的任务，事件创建时可以选择是否同步创建关联任务，任务创建时可以选择是否关联已存在的事件。
1、设计任务和事件的规则计算及存储⽅式
设计⽅案
1. ⾸先pass掉⼦任务全量落表的⽅式（⽆限重复规则的按时间落表往后半年或1年的数据），此⽅式对数据库的压⼒太⼤。
2. 采⽤存储任务规则的⽅式，对已经发⽣的任务落历史表，未发⽣的任务使⽤规则计算发⽣时间，未发⽣已修改的存特殊（special）
表。
问题
开源项目
1. 开发时间成本问题： 任务规则引擎设计，⼈⼒成本及时间成本太⼤。
2. 计算性能问题： 考虑到规则解析计算的性能可能会出现瓶颈，提出此问题。
解决⽅案：
1. 使⽤rfc-2445标准规范，选⽤开源项⽬组件。寻可靠的开源组件并测试其性能表现，最终经过Jmeter压⼒测试发现其性能瓶颈出
现在http的并发请求上，规则计算不是其性能瓶颈，为减少⽹络开销，最终对接⼝进⾏封装，采⽤⼀次请求计算多条规则的⽅式设计接⼝。
2. 对⼊⼝服务的接⼝采⽤redis缓存进⼀步缓解服务器压⼒，对常⽤接⼝的结果进⾏缓存，如⾸页的接⼝，由于其参数⼀天才变动⼀次，
所以完全可采⽤缓存的⽅式存储数据。
2、分布式事务解决⽅案
问题
微服务架构的系统中总会出现分布式事务的问题，例如：任务服务和事件服务为两个单独的服务，⽽任务与事件⼜有关联的操作，修改⼀条事件需要修改所有与此事件关联的任务，这就涉及到数据的⼀致性了，需要使⽤分布式事务来解决问题。
解决⽅式
解决分布式事务有很多⽅法，例如：基于可靠消息的最终⼀致性⽅案、TCC事务补偿型⽅案、最⼤努⼒通知型。
经过讨论，最终选⽤了最⼤努⼒通知型。详细设计⽅案为：调⽤对⽅服务时，判断是否成功，成功则流程继续，失败就把调⽤信息存⼊重试表中，然后继续下⾯的流程。最后使⽤定时扫描的⽅式重新发起接⼝的调⽤，重试调⽤⼀定次数，如果成功则结束，如果⼀直未成功则通知管理员处理此信息。
3、数据库与redis缓存的数据⼀致性
问题
在使⽤了缓存的业务场景中，例如查询⽤户的可访问资源，在修改数据库中的这些数据时，可能导致⽤户查出的缓存数据还是旧数据。
解决⽅式
设置redis缓存数据过期时间，修改数据时清除对应的缓存，使⽤户下次查询直接使⽤数据库的数据。
4、缓存穿透
问题
恶意⽤户发起攻击，查询⼀个缓存和数据库中都不存在的数据，造成⼀直查询数据库导致数据库压⼒飙升甚⾄垮掉。
解决⽅案
1） 接⼝增加⽤户权限校验，id做校验，例如 id<0 的直接拦截。
2） 在数据库中取不到的数据存⼀个空值到Redis，设置缓存有效时间较短，例如30秒后过期。
3） 使⽤布隆过滤器，布隆过滤器可以做到的效果：⼀个⼀定不存在的数据会被拦截掉，可能存在的数据才会去查数据库。因为这个特性，只要设置合理的参数就可以极⼤的缓解缓存穿透问题。
了解更多：
5、分布式锁
问题
本系统功能允许⼀个家庭组中存在多名管理员，所以存在多名管理员同时操作⼀条数据的可能性，为保证数据的⼀致性，需要对操作进⾏加锁处理，微服务中每个服务可能有多个实例，所以存在多个进程的线程操作同⼀条数据的情况，于是普通单机系统的应⽤使⽤的java内存锁不再可靠。
解决⽅案
分布式锁提供了分布式系统中跨JVM的互斥机制的实现，常⽤的分布式锁的实现⽅式有三种：
1、基于数据库实现分布式锁
2、基于缓存（Reids等）实现分布式锁
3、基于Zookeeper实现分布式锁
其中基于数据库的分布式锁实现⽅式最为简单，但是太过依赖数据库。Redis和Zookeeper中，因为Redis已在本系统中有集成，⽽且实现起来简单，只要注意Redis实现分布式锁的⽅式中的⼏个问题就能做出来⼀个相对完善的⽅案。PS：
6、消息的延迟推送
问题

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。