志愿填报系统,Spring框架爬虫开发 1、熟悉了Nginx负载均衡方案让访问分配到多台机器、cookie保持用户 session等状态信息的同步、Redis分布式缓存方案保持用户数据等数据缓存信息的同步、使用ftp共享文件系统上传文件的分布式架构模式。了解了springboot、jfinal极速 web 开发框架。 2、通过爬虫及日志采集

询价平台前后端开发，编码询价，流程设计，目录价计算 使用技术Spring、Mybatis、jalor5，数据库使用mysql、oracle；输入编码基于工作流引擎activiti流程分发，流程审批计算或获取目录价

我在项目中担任后端API接口开发任务 产品1.0版本：主要完成发布功能，评论功能，令牌机制，敏感词过滤服务，点赞服务，关注服务，异步服务，排行榜，异常统一处理机制 1.令牌机制：用来判断用户是否合法，登录状态是否正确，登录状态是否超时，如果合法则将对应的userBO保存在ThreadLocal中，在方便业务逻辑中调用 2.发布功能配合Threadlocal和七牛云文件服务器在nginx环境下保证并发访问 3.评论功能：针对评论主体类型划分，做了二级评论 4.敏感词过滤服务通过前缀树结构实现，服务启动加载数据库中的数据生成敏感词前缀树 5.点赞服务：使用redis-set缓存保存点赞记录 6.关注服务：使用redis-list集合做了关注服务，针对主体（帖子，用户）关注 7.排行榜：使用redis-sorted sets集合做了排行榜 8.异常统一处理机制使用AOP切面，拦截控制器返回的异常，分为未知异常，定义已知异常，参数异常，利用spring扫描机制，扫描异常properties配置文件，对异常信息统一管理 9.异步服务：使用异步服务的背景-进行点赞，评论，关注会对用户产生积分，消息推送，评论主体信息变更（文章点赞量增加，评论点赞量增加）为了保证用户的体验，设计异步服务处理一些功能出发的附加事件，使用生产者消费者模式，利用redis-list作为阻塞队列，将事件主体包装加入到队列中，然后由消费者线程死循环主动拉取消息交给不同消费器处理不同的消息 1.0版本产生的问题：无法确认消息是否被消费成功，会出现消息丢失的情况，同时增大了redis的负载压力，而且因为redis的心跳机制，redis客户端偶尔会被踢下线，通过定时任务，保证不会被踢下线，而redis异常宕机造成的数据丢失无法挽回 产品1.1版本：主要完成购物车、订单服务、优惠券服务【审核、投放、领取】、 分布式会话、单点登录、分布式锁、消息中间件基础组件服务、日志收集，权限控制 1.分布式会话：使用redis+cookie完成 2.单点登录：使用redis + cookie + 登录令牌 + 用户令牌 + 临时令牌机制完成,SSO【单点登录】:用户只需要在一个站点登录，那么其他站点也会随之登录，会话在不同的站点共享 CAS【中央认证服务】：独立的登录系统做验证 流程：初次访问/二次登录-验证是否登录【是否有全局令牌，是否有用户会话】-如果有用户会话，对请求地址增加临时令牌，进行验证操作，返回用户会话；如果没有用户会话，则重新登录-登录用户名密码，然后做验证，首先设置用户会话，用户全局令牌，将用户全局令牌返回给cookie，返回设置临时令牌的url，临时令牌会存入redis中，并对临时令牌设置有效期；验证临时令牌，如果存在，则验证request中携带的cookie中存在全局令牌，获取用户ID，然后在redis中获取用户会话，最后返回用户会话 3.消息中间件基础组件服务：利用rabbit-MQ实现，处理快速消息，确认响应消息，可靠性响应消息，批量消息，利用es-job做定时任务完成消费失败补偿机制； 为消息设定唯一标识:消息ID+时间戳+消息类型 自定义消息模板容器，有获取消息模板的方法和确认回调函数，为消息模板设定主题，路由规则，是否需要回调函数确认，并将消息模板保存起来，方便快速响应；确认回调函数，会根据消息类型做出是否需要确认的操作；使用异步连接池，提交消息到队列中，提高吞吐量 可靠性响应消息：在加入broker之前，先进行消息持久化，同时记录一条日志，保证消息和日志的原子性，之后将消息发送给broker，会执行回调函数，检测消息的ack是否成功，如果成功，则修改消息的状态为成功，同时修改日志的状态，保证原子性；如果失败，则修改消息的状态失败，并设定重试时间，重试次数，同时在日志中进行修改，保证原子性，通过定时任务补偿机制重试 更好的方法：在生产端和消费端都加上统一的消息代理中台服务，生产端和消费端都需要同步数据到消息代理中台服务，然后执行本地事务，如果成功则让消息代理中台服务发送这条消息，如果失败则事务回滚 批量任务通过threadlocal传递 4.商品秒杀：可以将数据库中所有的SKU缓存到redis中，进行下单的时候，检查redis中是否存在，如果存在并有库存，满足购买条件，则下单，进行支付，当支付的请求进入服务器的时候，首先检查redis中的SKU商品，如果被其他人抢走了，则支付失败；如果剩余的满足订单条件，获取分布式锁，加入消费消息到数据库中，并将消息发送给rabbitMQ-broker，扣除redis库存，支付成功，释放分布式锁，通过中间件更新mysql中的数据，如果服务器崩溃，可以通过数据库消费消息刷新库存和redis缓存 5.优惠券服务：优惠券可以用在不同的活动，商品类型中，通过后台分发 6.购物车：A. redis中无数据，如果cookie中的购物车为空，那么这个时候不做任何处理；如果cookie中的购物车不为空，此时直接放入redis中 B. redis中有数据，如果cookie中的购物车为空，那么直接把redis的购物车覆盖本地cookie；如果cookie中的购物车不为空，如果cookie中的某个商品在redis中存在，则以cookie为主，删除redis中的，把cookie中的商品直接覆盖redis中（参考京东） C. 同步到redis中去了以后，覆盖本地cookie购物车的数据，保证本地购物车的数据是同步最新的 7.订单服务：首先进行订单检查，生成订单号，返回给前端。对提交的订单信息总价进行检查，提交的商品数量进行检查，最大购买量进行检查，库存检查，如果使用了优惠券，对优惠券的使用范围，满减额度进行检查，检查优惠券有效期。如果都没有问题生成订单，将订单号返回给前端 8.分布式锁：使用redis实现 9.日志收集：使用ELK框架实现，通过filebeat对日志进行收集，交给kafka，通过Logstash过滤，交给es保存--该部分技术含量较少，主要依靠配置文件和技术总监的帮助 10.权限控制：后台权限控制通过角色-分组-功能的方式，通过注解的方式，对用户信息拦截检查，用户的权限是否满足注解条件