spring-session

spring-session之5 redis集群配置步骤总结 - 飞天奔月的java博客 - ITeye技术网站

spring-session之4 redis集群配置 - 飞天奔月的java博客 - ITeye技术网站

Spring客户端对Redis 缓存的使用(Java客户端等Redis3.X RedisCluster模式的支持) - 不能说的秘密的博客 - 博客频道 - CSDN.NET

redis集群搭建之二~使用redis-trib.rb方法 - 每一个不曾起舞的日子 都是对生命的辜负 - 博客频道 - CSDN.NET

redis cluster 集群架构 - 每一个不曾起舞的日子 都是对生命的辜负 - 博客频道 - CSDN.NET

亿级PV超大型网站集群架构图形化深度揭秘讲解 - CSDN学院 - CSDN.NET

Tomcat多实例Session共享的原理 - 知乎专栏

通过Spring Session实现新一代的Session管理

Git的安装与使用（自建的Gitlab系统的使用） - stay hungry,stay foolish - 博客频道 - CSDN.NET

车辆质押贷款

车辆保管 一车多押 车辆处置资源（原本按揭贷款）

车辆抵押贷款 预过户装GPS（信号）

Tomcat可以多给你做一点就是跨应用的session共享。配置两个项目的context可以互相访问 crossContext

ip_hash hash也好，upstream也好，都有个很严重的弊端

假设其中某台down掉了，估计是两种方案

1：其他的应用服务器接纳这台的用户，重新生成session，这种情况下，当应用服务器恢复以后，这些老用户就回不来了

2：放弃这些用户，直到应用服务器重新启动，这样保障部分用户一直ok（个人欣赏这种做法）

当然，最好的办法是不是用session，session这个玩意总是个祸害

ip_hash

1/ nginx不是最前端的服务器。ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。

2/ nginx的后端还有其它方式的负载均衡。假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服务器。最好的办法是用 location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。

tomcat+redis

这种方式只能让两个tomcat下相同的应用名的session共享，比如在tomcat下新建一个test2工程，test2和test的session不是同一个。也就是说这种方法只能适用不同tomcat同工程，不能适用同tomcat不同工程。

只有在server.contextPath相同的情况下才能共享

数据量评估

• 测试：单机写入2000w业务数据，占用内存1.5g，本机126g内存
• 评估：单机的稳定数据承载量：2000w（126/1.56） 0.6 = 96923w
• 结论：9T 的数据承载量，远超当前千万级别的数据量

性能评估

• 测试：简单压测了下 
  • 写操作 1000w，80%在20ms一下 ，98%在30ms，最大218ms，qps 5w/s，总耗时197s
  • 读操作 1000w，97%在10ms一下 ，99.99%在24ms，qps 6w/s，总耗时160s
• 评估：当前的调用量在千万每天，qps的话在百/s。
• 结论：当前单机的redis完全满足需求

主从：

2.2 配置读写master

• 修改端口：port 【目的：简单的修改默认端口是最好的防攻击】
• 添加密码：pwd
• 关闭压缩：rdbcompression no 【硬盘最够，降低cpu的能耗更利于提升性能】
• 开启守护进程：daemonize yes【master开启守护，增加稳定性】
• 关闭protect-mode :允许他机器访问
• 添加白名单：bind xxx
• 修改log地址，pid地址和数据存储地址：logfile pidfile【便于维护和安全】
• 添加慢查询：slowlog-log-slower-than 500【根据业务需求，便于优化】
• 最大内存限制：maxmemory 【考虑稳定性和性能，一般不超过最大内存的60%】

2.3 配置只读slave

• 同master
• 设置主库:slaveof ip:port
• 主库密码：masterauth masterpwd
• 只读：slave-read-only yes

3.1 容灾能力

• 主动容灾 
  • 备份：master 全量备份，slave全量备份。
  • 备份安全：本机保存，hadoop同步保存一份。
  • 监控和探活：监控机分钟级探活和预警
• 被动容灾： 
  • slave 宕机：重启之后直接从master恢复
  • master 宕机且硬盘数据为损坏：重启后数据自动恢复且和从库一致。
  • master 宕机且数据损坏：删除损坏数据，使用slave1的数据恢复，保证数据一致。
  • master 和slave 1 同时宕机：slave2 保证读正常，业务不影响，利用slave2 数据备份恢复master，启动slave 即可
  • 三台全宕机：服务挂掉，从hadoop获取数据恢复服务。