自我介绍**自我介绍
不，我毕业于湖南湘潭大学。 有必要明确说明自己的个人信息。 从哪里来很重要。 介绍个人经验，介绍以前公司的情况。 *
我来自湖南省郴州，本科就读于湖南湘潭大学，学习电子信息科学与技术专业。 到现在为止开发已经三年了。 三年来先后就职于两家公司，北京全网数商科技有限公司、北京科莱特信息技术有限公司、我pgrjb从事Java开发
工程师岗位。 三年间共参与了五个项目的开发。 前面几个项目都采用了单一的体系结构和垂直体系结构。 最近的两个项目是电子商务项目。 在这两个电子商务项目中，我们的体系结构采用分布式系统来应对商城的高并发访问，实现了商城系统的高可用性。 collect EC重构项目中使用的体系结构旨在基于以前大量的EC项目进行改写和重构。 解决以前项目中可能存在的问题。 优化大规模并发处理。 通过分布式架构实现系统的高可用性和可扩展性。 增加预约、预售等电子商务常用功能整个项目采用Springmvc Mybatis Spring Dubbo框架开发，我在这个项目主要是搜索系统、用户注册、短信微服务发送
我最近做的这个项目叫那个网。 那个网络是贵州省主要的贵州特产和其他商品的B2C项目。 以SSM集成框架为主体框架，结合分布式远程rpc调用框架dubbo，实现商城项目的高可用性和秒杀时的高并发。 项目内容项目中
采用MySQL数据库集群、redis分布式缓存缓解数据库压力，实现了高可用性。
使用SolrCloud分布式集群技术优化商城搜索，
使用Nginx进行负载均衡，使用ActiveMQ解决分布式系统中过于依赖服务层的问题。
使用FreeMarker模板引擎实现网页静态化，优化首页和商品详细信息页面的显示速度。
使用CAS单点登录解决分布式系统的登录问题。
网站前端采用谷歌优秀的前端MVC框架angularJS进行前后端分离，加快了开发速度。 另外，进行了分层结构和公共代码提取，使程序的维护变得容易了。
本项目主要参与了CAS单点登录、检索系统、商品详细系统、购物车系统、订单系统等模块的开发。
让我简单说明一下这些功能模块是如何实现的。
具体见CAS单点登录
单点登录模块的故事是为了解决我们分布式系统中的登录问题。 商场项目有多个子系统，SSO的定义是在多个APP应用系统中，用户只需登录一次就可以访问所有相互信任的APP应用系统，无需重复，可以多次系统登录他可以将这次的主要登录映射到其他APP，统一用户的登录机制。 他是现在流行的登录方式。
用户如何通过一次登录就可以访问所有相互信任的APP应用程序系统，并获得所有其他系统的信任？ 我们如何产生并保存那份信任呢？ 以及其他系统如何验证这种信任的有效性。 这里使用cookie作为证书媒体。 保存登录的票证，使用jsonp实现跨域登录。 在我登录这个单点登录系统之后，实现面向页面的三位一体解决方案。 无论门户系统、数据系统，它们都可以直接以此票证为媒介直接验证，无需向其他系统进行二次注册。
首先登录后，用源加密方式对密码进行加密，然后在数据中进行询问，确认是否有用户名与用户输入的密码一致的数据。 如果有，请生成ticket票证，即用户证书，并在ticket前面加上key。 用户json字符串作为value存储在redis缓存中。 (缓存时间设置为1h，每次搜索时都会重新设置。 它还将cookie用作介质，保存用户证书，将cookie设置为可跨域请求，将cookie设置为会话级别，然后关闭浏览器以禁用cookie。
用户登录父APP后，在用户访问子APP时，携带该cookie，通过jsonp实现跨域支持，验证用户登录状态，通过后登录用户，最后往返于父APP和子APP进行提取实现信息的安全传递，如果用户尚未登录或登录超时，则返回登录页面，用户输入帐户密码后重新登录。
搜索系统
对于搜索系统，由于查询的数据量很大，所以使用的是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 搭建