该项目是一款论坛类项目共有12个模块，其中主要的有model用于存储实体类和Dto，utils封装一些该项目用到的工具类，common做一些全局异常处理和各种常用公共类，等等，该项目的亮点是使用MinIo对文章进行存储，使用redis对一些热点数据进行存储，从而减轻数据库的读写负担，数据库的设计采用的是垂直拆分思想，让数据分类存储。 •技术架构： 1.Spring + Springboot + Springcloud + MybatisPlus + MySQL + Redis +MongoDB+Minio +freemarker + Kafka •职责描述以及技术描述： 1.使用MinIo完成完成文章图片的上传和下载，并结合freemarker完成静态页面的展示； 2.阿里云云盾查检测敏感字 3.项目内容在自媒体模块采用mysql为主，MongoDB为辅完成了用户的点赞，评论，转发，建立好友 等一系列功能； 4.采用第三方阿里DFA技术完成对文章内容敏感词的检查和违规图片的审核； 5.使用自定义线程池完成异步调用，提高回馈效率； 6.使用Redis缓存提升用户对同一文章查询阅览的效率，并记录用户阅览足迹和发布内容草稿箱功能；

智云展业CRM是一个客户关系管理系统,我们为中国大地财产保险有限公司定做的客户管理系统,这家公司在客户关系管理方面面临很多问题,包括,市场部门渠道增多,线索量增大,市场的客户需要客户细分,分配业务人员对于客户信息的跟进信息和记录,管理者对于销售目标的设定,销售计划的统计等,智云展业CRM主要为了企业销售人员提供以下服务: 第一,辅助销售人员对销售线索,商机,客户进行跟进转化,提高转化率,实现销售线索的价值最大化 第二,为企业提供自动化营销服务 第三,对销售业绩,销售趋势进行数据汇总分析 第四,销售数据统计为销售管理工作提供依据 第五,为优化公司的业务发展,提供数据支撑 •技术架构： •Springboot + Springcloud + MybatisPlus + JWT + MinIo + MySQL + Redis •职责描述以及技术描述： 1.基于线程封装和拦截器使用JWT统一进行token的认证完成对用户的校验以及用户的注册； 2.项目内容在线索，商机等模块采用mysql为主，redis为辅对已成交客户的读写更快，方便维护销售人员客户 3.使用自定义线程池完成异步调用，提高回馈效率； 4.使用EasyExcle通过excle批量添加线索

它是一个他是一个新闻资讯类型的项目，采用SpringBoot+SpringCloud架构搭建的。该项目由三部分组成，分别是APP端、自媒体作者端、管理端，app端主要面向用户是那些对时尚打扮感兴趣的群体，用户可以阅读我们作者提供的文章以追踪最新流行的时装打扮；自媒体作者端主要面向我们文章的作者；管理端主要是供内部的管理人员使用。我当时负责自媒体端和APP端的部分模块开发，其中自媒体作者端下有一个文章发布的模块，该模块下有一个审核自媒体文章和发布文章的业务。这个文章发布的时间由自媒体作者自由选择，可以立刻发布也可以选择任意的时间定时发布。 我刚开始做这个定时发布文章的时候想到了用队列来实现，然后思考了两种方案：一种是用JDK自带的DelayQueue阻塞队列来实现，另一种是用rabbitmq的延时队列+死信队列来实现。对比了这两个方案我发现DelayQueue(得来Q)只适用于单个微服务之中，而文章发布的话涉及到了APP端的微服务调用，所以我就选用了rabbitmq这个方案。这个方案呢，是这样的：自媒体端的文章微服务作为消息的生产者，app端的时装微服务作为消息的消费者。在文章审核通过在之后，将文章id以消息的形式发送到rabbitmq的延时队列，并设置消息的存活时间为发布时间毫秒值减去当前时间毫秒值得出的时间差，消息一旦超过设置的存活时间，就会转到死信队列，消费者监听到死信队列消息后对文章进行发布。 在业务完成之后我做了测试，在某次测试当中我发现了一个BUG，就是这种实现方式会造成一个消息阻塞而导致文章发布时间延迟问题。我模拟了两篇文章做测试，A文章先提交审核，设定发布时间为5分钟后，B文章在A文章之后提交审核，设定发布时间为3分钟后。然后生产者会将A文章id先于B文章id发送到延0时队列，B文章id的三分钟存活时间到了但是并没有转到死信队列，因为A文章id的五分钟存活时间还没到，将B文章id阻塞了，这就导致了B文章的实际发布时间与预设的发布时间相差太远。 所以rabbitmq的延时队列+死信队列这套方案其实不适合做时间值不固定的延时任务，只适合做固定时间值的延时任务，比如像抢票软件抢到票超一个小时未支付就会取消的场景。后来我想了挺久都想不到用什么技术实现这样场景的延时任务，就上网搜了一下，发现了一种使用Redis的ZSet来实现的方案。 然后我就试了一下这种方案，发现还挺不错的，这个方案是利用Zset的menber(曼波)都会关联一个score(死沟)作排序这一机制来做延时队列的。这个方案流程是这样的：文章审核通过之后，将固定的任务id作为key、文章的id作为Zset的menber、发布时间的毫秒值作为score(死沟)存入redis中，就是以Zset作为一个延时队列，但是光这么做会导致redis存入的数据太多而影响性能的问题，我就用了mysql辅助，把定时发布任务都先存到mysql，只有发布时间在五分钟之内的才会存入redis，然后用spring的schedule(晒竹)定时器定时四分钟去mysql同步5分钟之内的任务到redis，同时还用另一个schedule定时器每秒去获取延时队列的消息，拿到每篇文章的发布时间，如果发布时间小于或等于当前时间，就立刻发布文章。这个方案就解决了rabiitmq的阻塞问题。 但其实这个方案用到了schedule，又产生了另一个小问题，就是一旦我这个微服务搭建集群的时候，每个节点的schedule定时器都会在同样的时间去做同样的任务，造成系统资源的浪费，于是我就用分布式任务调度xxl-job来替换schedule，使用xxl-job的轮询策略调度每个节点依次执行任务。