java程序员自我介绍

自我介绍

**自我介绍

1. 来自哪里,毕业于湖南湘潭大学,需要把自个人信息交代清楚,来自哪里是比较重要的.
2. 介绍个人经历,上家公司情况
3. 介绍项目**
   我来自湖南郴州,本科就读于湖南湘潭大学，学的是电子信息科学与技术专业， 开发至今已经三年了，三年期间就职于两家公司，北京全网数商科技有限公司和北京柯莱特信息技术有限公司，我在里面从事的是Java开发
   工程师的一个岗位。三年期间总共参与开发了五个项目，前面的几个项目都是采用的单一架构和垂直架构，最近的两个项目是电商项目，在这两个电商项目中我们的架构都是采用的分布式系统来应对商城的高并发访问，商城系统的高可用。在柯莱特电商重构项目中使用的架构是目在以前大量电商项目基础上进行重写，重构。解决以前项目中存在即可能存在的一些问题。优化大并发下的处理效。通过分布式架构来实现系统的高可用和，和可扩展性。添加抢订、预售等电商常用功能 该项目整体采用的是 Springmvc + Mybatis + Spring +Dubbo框架开发，我在这个项目中主要负责搜索系统、用户注册、发送短信微服务等功能模块的开发以及完成上级分配的其他任务。
   在我最近做的这个项目叫那家网，那家网是贵州省的一个主打贵州特产及其他商品的B2C项目。以SSM集成框架作为主体框架，配合分布式远程rpc 调用框架 dubbo，实现商城项目的高可用与秒杀时的高并发。

项目内容

项目中
• 采用了MySQL 数据库集群、redis分布式缓存缓解数据库压力以及实现高可用，
• 使用SolrCloud分布式集群技术优化商城的搜索，
• 使用Nginx进行负载均衡，使用ActiveMQ解决分布式系统中表现出过分依赖服务层的问题。
• 使用FreeMarker模板引擎实现网页静态化优化首页及商品详情页面的显示速度，
• 使用CAS单点登录解决分布式系统的登录问题。
• 网站前端采用Google的优秀前端MVC框架angularJS进行前后端分离，加快了开发速度，并且进行了分层架构与公共代码抽取，使程序更加容易维护。
这个项目中开发方面我主要参与了 CAS 单点登录、搜索系统、商品详情系统、购物车系统，订单系统等模块的开发。
下面我简单讲一下这些功能模块是如何实现的吧，

具体实现

CAS单点登录
单点登录模块的话是为了解决我们分布式系统中的登录问题，因为商场项目有多个子系统，SSO的定义是多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统，不需要重复，多次系统登录。他可以将这次主要的登录映射到其他的应用中，用于统一用户的登录机制，他是目前比较流行的登录方式。
我们怎么做到用户只需要登录一次就可以访问所有相互信任的应用系统，能够得到其他所有系统的信任。我们怎么产生和存储那个信任。再就是其他系统如何验证这个信任的有效性。这里我运用的是cookie作为凭证媒介。存储一个登陆的票据，采取jsonp实现跨域登陆。页面定向实现三位一体的解决方案，就是我一旦在这个单点登录系统登录以后。不管是门户系统，数据系统，这些都可以直接凭借这个票据作为媒介直接去验证，不用在其他系统进行二次登录的。
首先登录后，我们将密码按照源加密方式加密后到数据里面查询，看是否有与用户输入的密码与用户名匹配的数据。如果有，我们生成一份ticket票据，也就是一个用户凭证，以ticket加上一个前缀作为key。用户json字符串作为value，存入redis缓存中，(缓存时间设置为1h，且每次查找的时候都再设置了一次)。并且使用cookie作为媒介，存放用户凭证，将cookie设置为可以跨域请求，cookie过期设置为会话级，关闭浏览器cookie失效。
用户登录父应用之后，当用户访问子应用的时候，携带上这个cookie，通过jsonp实现跨域支持，验证用户的登录状态，如果通过验证则登录用户，最后通过父应用和子应用来回重定向中进行通信，实现信息的安全传递，如果用户还没有登录，或者登录超时，则返回一个登录页面，用户输入账号密码再次进行登录。
搜索系统
搜索系统的话由于查询的数据量很大所以使用的是 solrCloud 分布式集群，集群原理和搭建：使用了5台zookeeper 和 12台 solr搭建集群部署，我们在搜索的时候并不需要把商品的全部信息给显示出来，所以只需要同步必须的字段到索引库就好了，如商品的标题，价格，图片，id，卖点。并使用了一个keywords复制域复制了商品的标题，分类，卖家，品牌的信息来作为关键字搜索。搜索的时候用户输入关键字的话根据用户输入的关键字，将keywords 作为搜索域，进行分页查询，得到我们想要的数据后将用户输入的关键字作高亮显示。可以让用户直观的感受到自己搜索的商品中有自己的查询结果。当商品更改之后需要对索引库进行更新，我们采用MQ 异步的方式同步索引库。当商品发生改变的时候，发送通知到消息队列通知索引库进行更新。这样系统的耦合度就大大降低了。
购物车和订单系统
购物车模块，在用户未登陆的情况下，将购物车中的商品存进cookie中，登陆的情况下，将购物车存在redis中，同时也把cookie中的商品合并到redis中。判断购物车商品，有相同的商品，进行数量上的计算，没有该商品，直接放进redis中。
我们把购物车商品的集合对象转换为JSON格式放进cookie中，设置cookie的有效时间为1天。
而redis我们是用键值对来购物车商品的，键用 cart 拼接用户名，值就是购物车商品的集合对象。
并且在用户查询购物车列表的时候判断是否有用户登录，有就先判断cookie中是否有数据并且把cookie中的商品合并到redis中，再取数据，没有登录就从cookie中取数据并且返回到页面。
订单系统。这里购物车系统的数据我们是存放在redis 中的，点击订单结算页的提交订单 ，将购物车保存到订单表和订单明细表中，并将购物车数据清除
秒杀系统的实现
秒杀技术实现核心思想是运用缓存减少数据库瞬间的访问压力！读取商品详细信息时运用缓存，当用户点击抢购时减少缓存中的库存数量，当库存数为0时或活动期结束时，同步到数据库。 产生的秒杀预订单也不会立刻写到数据库中，而是先写到缓存，当用户付款成功后再写入数据库。
商品详情系统：
商品详情在商品审核之后利用 Freemarker 模板生成商品静态页面并结合 Nginx 实现商品详情页面静态化；在同步的技术调
研分析中选择了可异步、持久化的 ActiveMQ 进行同步信息的传递并最终实现近实时的商品同步到搜索系统、详情系统。当运营商系统审核通过商品之后，首先会修改数据库的状态，然后发送消息到消息中间件
Nginx 实现静态资源服务器
Nginx 实现静态资源服务器并发量可以达到每秒5W 次，因为商场系统很多图片等一些其他的静态资源，那么如果每次请求都通过Tomcat 服务器的话，势必会很影响性能，而静态资源服务器可以很好的解决这一个问题，将一些不常发生改变的静态资源比如，图片音频，js、css等静态资源放到静态资源服务器，当用户请求页面加载的时候Tomcat 只负责返回用户请求的数据，而页面上的样式，图片等资源通过静态资源服务器获得，这样的话可以有效的缓解Tomcat 服务器的压力，提高响速度。针对商品详情页面的话，如果没有静态资源的话就去 Tomcat 上面去访问由于是使用的 freemarker 模板引擎，那么读取速度也是很快的。
spring boot 集成短信微服务
springboot 集成短信微服务，就是将服务分解出来，保持单一职责原则，就算发送短信的服务宕机也不至于影响其他业务。所以基于以上考虑的话，使用springboot 快速的搭建短信微服务，通过 MQ 发送消息的方式来通知短信微服务。而且这个短信微服务可以复用，就是商城的其他子系统需要发送短信的话，就发送消息到消息队列就可以了。非常的方便。
ActiveMQ 的使用：
对于分布式系统来说，MQ 肯定是必不可少的，比如分布式商城系统中的运营商系统，对各个服务的调用关系最多，用到了商家商品服务、内容服务、搜索服务。这种模块之间的依赖也称之为耦合。而耦合越多，之后的维护工作就越困难。那么我们就是使用的 MQ 改善系统模块调用关系、减少模块之间的耦合、提高系统的吐吞量。举个简单的例子吧，运营商那边审核商品通过之后，需要更新索引库和数据库，还有需要使用 freemarker 创建商品详情的静态页面，如果使用同步的方式处理的话，这期间的耗时是比较多的，而且服务之间的耦合度也很高。那么我们就使用 MQ 来解决这一个问题，比如审核通过之后，只需要更新数据库，然后发送消息到 MQ 之后就响应用户请求，而 MQ 的消费者接收到消息之后就处理相应的业务，这样就达到了异步处理。而且就算其中某一个业务出了故障也不会影响其他业务。实现了解耦和高可用。而ActiveMQ 每秒 5W 的吞吐量对普通的商城项目来说完全够了。
ActiveMQ 集群
使用了三台zookeeper，来管理 ActiveMQ，为了实现高可用，首先三台zookeeper 集群，然后配置 三台 ActiveMQ 集群，ActiveMQ 中有一台是master 另外两台是 slave。 如何实现高可用呢？ActiveMQ的客户端只能访问Master的Broker，其他处于slave的broker不能访问。所以客户端连接Broker使用failover（失败转移）协议，即谁正常就连谁。 当 ActiveMQ 的 master 挂了之后，slave选举出的master将能够访问，而zookeeper 挂了一台是不影响的。做到了高可用，集群至少要有两台zookeeper 和两台 ActiveMQ 在线。
死信队列：消费者，也就是监听器监听了指定的队列开启事务之后，如果执行业务代码期间出现问题的话，那么生产者那边会默认再重发6次，如果6次消息还没有被消费掉，那么就会被放到死信队列。
redis的使用
持久化策略
首先，持久化策略，redis 的持久化机制分为两种，RDB 和 AOF 默认情况下的话使用的是RDB
RDB: Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb ，默认情况是 900 sec 中之内如果有一个 key 发生改变的就保存，300sec 之内如果10个 key 发生改变就保存， 60sec 之内一万个 key 发生改变就保存。一般来说使用默认的持久化策略就好。
AOF：默认情况是没有启用的，需要自己启用。原理是使用命令日志的方式，redis 可以设置将每次执行的命令保存到磁盘中，或者设置每秒中将命令保存到磁盘中。
使用 RDB 的方式性能会好点，直接是快照放到内存中。而使用 AOF 的话恢复的时候会将上面的命令都执行一遍。如果对于一些不能丢失的数据的话，可以将两种方案都结合起来使用。
主从复制
redis 的主从复制为了提高性能做读写分离。主可以写入，而从只能读取，需要在从redis 中配置
redis 集群搭建
redis 集群搭建，两种方案，一种是使用自带的 redis-cluster ，至少需要 6 台Tomcat ，一种是需要第三方代理，比如codis 搭建