项目职责：三、优信通信 Unified Communications 2004/1-2010/12 项目: 智能电话监测系统 项目描述: 一． WEB项目 二． （一）项目经验: Intelligent Call Monitoring System（智能电话监测系统） 三． 技术选型: Spring、Struts、Hibernate、JavaBeans、Jsp , 四． Server: Tomcat 5.0 五． 开发工具: MyEclipse 或Eclipse 六． DB: Mysql 七． 报表: IReport 和 Jasperreport , JFreeChart。 八． （二）曾经参与开发的系统: 九． 1) : 手机预付费系统 用jsp+java+Mysql开发 十． 2) : 青海联通PRBT（PERSON RING BACK TONE）系统(JSP+Java+mysql开发)。 十一． 二．后台模块

项目职责：.23 项目职务 游戏服务器主程 项目名称: 盗墓笔记手游，战国之王手游，最强弃少手游，后台管理系统，充值系统 ，H5微信小游戏: 命运之剑，山河手游，使命页游，神奇便利店，神奇娃娃机。 1.在技术开发部担任java服务器主程，研究了多种框架和多种技术，并作为研发部门的骨干参与讨论和开发。 2.游戏服务端采用分布式架构，分为网关服务器，登陆服务器，账号服务器，游戏服务器，战斗服务器。 3.技术选型: 以netty作底层网络架构，socket， protobuf为作通信协议，c3p0数据库连池, MySql数据库永久层，内存数据库（自己封装内存数据（key-Value）），数据主线程同步到MySql，多线程，线程池。 盗墓笔记，最强弃少: 以RPG的角色成长玩法为核心，植入SLG元素，以卡牌为核心战斗模式。 战国之王: 战争策略，SLG 以盗墓笔记手游为例: 单服务器（8核，16g内存）可承载6000人同时在线. 现己开近600多个服 Web端: 1.后台管理系统: 方便运营游戏如开服，停服，给玩家发物品，发系统邮件，发布运营活动等等，查看游戏数据。 2.充值系统: 1）nginx作为前端负载匀衡，后端Tomcat集群运行充值系统 2）App端向充值系统发送登陆验证，充值系统再向SDK平台验证App端后，SDK平台向充值系统回调充值结果，充值系统再向游戏服发送玩家充值信息。 3．数据中心:

项目职责：工作经历 1.Web项目商城 1、商品信息，购物车，订单等服务模块的接口开发； 使用CompletableFuture 异步编排解决查询商品详情⻚响应速度慢的问题；使用RabbitMQ延时队列实现未付款订单，超过一定时间后，系统自动取消订单并解锁库存；使用Redisson分布式锁解决分布式系统下商品重复上架的幂等性问题；使用Spring Schedule定时任务提前上架抢购商品信息到Redis缓存中实现库存预热功能 2、 该系统架构 用采用SpringCloud架构，利用SpringBoot构建应用，利用Nacos作为服务的注册、配置中心，利用OpenFeign实现与其他模块进行交互，利用Sentinel实现熔断降级和错误处理，利用Gateway作为服务网关，利用RabbitMQ实现延迟队列，利用Redis作为缓存解决读多写少的场景，利用MySQL进行持久化，利用MyBatisPlus作为持久化框架。 Seata: 即分布式事务(自己用的后台)，处理订单（MQ实现柔性事务） 技术点: 1) nginx反向代理,负载均衡到关网群，再由网关负载均衡路由到微服务群;nginx动静分离。 2) nacos 注册发现(服务高可用)， 配置中心: 统一管理配置，热读取配置文件，使用命名空间实现环境隔离（开发，测试，生产），每个微服务之间相互隔离配置，每个微服务创建自己的命名空间，只加载自己命名空间下的所有配置 3) OpenFeign远程调用(rpc) 4) Springboot2.0以后默认使用lettuce作为操作redis的客户端使用netty进行网络通信。lettuce的bug导致netty堆外内存溢出。解决方案: 不能只是调大(-Xms500m)堆处内存，切换使用jedis。 可能由于lettuce没有及时释放掉链接 5) 缓存问题 1--缓存穿透(解决: null结果缓存，并加入短暂的过期时间), 2--缓存雪崩--(解决: 原有原失交时间基础上增加一个随机值 1-5分钟随机 ,这样每个缓存的过期时间的重复率会降低，就很难引发集体失效事件 3--缓存击穿(解决: 加锁，大量并发只让一个去查，其他人等，查到后释放锁，其他人获取到锁，先查缓存，就会有数据，不用去db，或者把这些热点数一直放在缓存不失效) 6) 分布式锁 使用Redisson不会有死锁问题，锁的粒度越细，越快 “product-lock-19” 1--分布式锁自动续期，如果业务超长，运行期间自动给锁续上新的30s,不用担心业务时间超长， 锁自动过期自动删掉 2--加锁业务只要运行完成，就不会给当前锁续期，即使不手动解锁，锁默认在30s以后自动删除,最好还是手动解锁 3--一般使用3种分布式锁 分布式读写锁 ReadWriteLock，分布式信号量 可以作为分布式限流（每个应用），分布式闭锁 7) 分布式闭锁分布式缓存 一致性 1--双写模式,失效模式 脏数据问题 这是时性的脏数据问题，但是在数据稳定缓存过期的以的，又能得到最新正确的数据，如果不能容忍一定时间暂时性脏数据，这时需要用分布式锁，如果可以，则只需要最终一致性 2- -用户数据(订单数据，用户数据)这种数据由于并发几率非常小不需要考虑这个问题， 3- -菜单，商品介绍等基础数据，可以用canal订阅binlog方式 4- -缓存数据+过期时间足够解决大部分业务对于缓存的要求 5- -遇到实时性，一致性要求高的数据，应该通过直接操作数据库 8) Gateway 1- -请求一般都是先到达网关，网关先利用断言来判定此次请求是否符合某个路由规则，如果符合路由规则，就会按照这个路由规则，经过一系列的过滤器过滤之后，发送到指定的地方 9) OAuth2.0 社交登陆，单点登陆 1- -短信验证码发送，短信验证码防刷，验证码再次验证 2- -微博社交登陆实现， 10) 分布式session springSession,redis 只能放大到一级域名 1- -解决同一个服务集群环境，session不同步问题 2- -解决不同服务，子域session不能共享问题 11) 单点登陆