天学到的技术点二
天学到的技术点2
JMS
JMS的全称是Java Message Service
http://elim.iteye.com/blog/1893038
JMS消息监听器(kafka也有的)
http://elim.iteye.com/blog/1893676
JMS事务管理
http://elim.iteye.com/blog/1983532
P2P模式：每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
Pub/Sub模式：
ActiveMQ工作模式：
http://blog.****.net/qq383264679/article/details/51163144
JMS开发步骤和持久化/非持久化Topic消息
https://www.cnblogs.com/xinhuaxuan/p/6105985.html
Interceptor拦截器与AOP的区别
SpringMVC中使用Interceptor拦截器
它的主要作用是拦截用户的请求并进行相应的处理。比如通过它来进行权限验证，或者是来判断用户是否登陆，或者是像12306 那样子判断当前时间是否是购票时间。
http://elim.iteye.com/blog/1750680
Interceptor拦截器（拦截请求，与过滤器有点类似）与AOP（拦截一个面，不一定是请求，一个方法也可以）
mybatis动态SQL详解
http://www.blogjava.net/stevenjohn/archive/2012/12/25/393451.html
RocketMQ
http://www.jianshu.com/p/453c6e7ff81c
通过同一订单发送到同一个服务器队列，从而保证顺序性
重复性消费，可以
1.保持幂等性，不管来多少条重复消息，最后处理的结果都一样。
2.利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息。
事务消息
1.直接将发消息放到Bob扣款的事务中去，如果发送失败，抛出异常，事务回滚。（业务上实现）
解决activemq多消费者并发处理
http://blog.****.net/Seven__________7/article/details/71854992
activemq有一定机制将队列中的数据交给consumer处理，这个机制就是数据的数量分配，查资料得知，默认是1000，因此，把这个值调小就可以了。
二维码生成工具
MatrixToImageWriter
Bitmatrix
修改请求和响应内容
HttpServletRequestWrapper、HttpServletResponseWrapper
http://blog.****.net/it_man/article/details/7556903
springboot 多环境配置文件的选择
spring.profiles.active
http://www.leftso.com/blog/111.html
maven 多环境配置文件的选择
http://xj84.iteye.com/blog/1135594
https://segmentfault.com/a/1190000003908040
http://zhaoshijie.iteye.com/blog/2094478
页面URL访问统计
DruidWebStatFilter
http://blog.****.net/u011831754/article/details/71631622
解读分库分表中间件Sharding-JDBC
http://blog.****.net/cxboyee/article/details/50672969
如何高效生成趋势有序的全局唯一ID。
类snowflake算法
https://www.cnblogs.com/relucent/p/4955340.html
秒杀系统架构优化思路
1.将请求尽量拦截在系统上游
2.充分利用缓存
浏览器和APP：做限速，每5秒只准请求一次
站点层：按照uid做限速，做页面缓存，返回5S内相同的内容
服务层：按照业务做写请求队列控制流量，做数据缓存，按数据进行后面罗辑的处理，其他返回结柬信息
回仓，未支付的回仓，告诉客户多少分钟后进行重次（如45分钟）
架构设计原则之一是“fail fast”。
做请求队列控制流量
http://shift-alt-ctrl.iteye.com/blog/2315008
easyUI
http://demo.topjui.com/?s=jeasyui
实现线程的阻塞和继续运行（针对当线线程用的），用到做请求队列控制用
LockSupport
http://shift-alt-ctrl.iteye.com/blog/2315008
Semaphore 提供同时访问的数量限制
synchronized、ReentrantLock 是对一个资源并发的控制,单一访问
线程阻塞、唤醒：LockSupport
wait(), notify(), notifyAll()，线程阻塞、唤醒，wait使当前线程等待
同一个账号，一次性发出多个请求.解决为写入标志位
多个账号，一次性发送多个请求.解决为频率高就用验证码或同IP数据限制
多个账号，不同IP发送不同请求.解决为提高帐号的等级要求才可以参加
容量设计
容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等
峰值QPS大概是均值QPS的2.5倍
单机极限QPS，压力测试
互联网架构设计如何进行容量评估：
【步骤一：评估总访问量】 -> 询问业务、产品、运营
【步骤二：评估平均访问量QPS】-> 除以时间，一天算4w秒
【步骤三：评估高峰QPS】 -> 根据业务曲线图来
【步骤四：评估系统、单机极限QPS】 -> 压测很重要
【步骤五：根据线上冗余度回答两个问题】 -> 估计冗余度与线上冗余度差值
单点系统存在的问题
（1）单点系统存在的问题：高可用性问题，性能瓶颈问题
（2）shadow-master是一种常见的解决单点系统可用性问题的方案，keepalive
（3）减少与单点的交互，是存在单点的系统优化的核心方向，常见方法有批量写，客户端缓存
（4）水平扩展也是提升单点系统性能的好方案,DNS解析到不同的nginx外网IP，多个nginx
后台管理界面可以用frame的方式进行不同页面用不同js的层级关系，每个界面都要请求后放到frame中，
用户端就还是用页面路由的方式，以减小页面的请求，frame不适用于用户端(大量用户的前端)
缓存
（1）淘汰缓存是一种通用的缓存处理方式（而不是同步更新）
（2）先淘汰缓存，再写数据库的时序是毋庸置疑的（防止缓存淘汰失败）
（3）服务化是向业务方屏蔽底层数据库与缓存复杂性的一种通用方式
冗余表数据一致性
1.服务层同步写冗余数据
2.服务异步写（引入消息总线）
3.线下异步写(与数据库binlog原理一样)
4.按业务来定先写那个冗余表，影响大的先写
5.线下全量或增量对数据一致性检查
6.用消息对的方式对数据一致性检查（消息对出现的时间一般在3S内）
缓存与数据库一致性保证
1.先淘汰缓存，再写数据库。
主从DB与cache一致性（有一个同步时间问题）
可以用二次异步淘汰的“缓存双淘汰”法来解决缓存与数据库中数据不一致的问题，
（1）timer异步淘汰（本文没有细讲，本质就是起个线程专门异步二次淘汰缓存）
（2）总线异步淘汰
（3）读binlog异步淘汰
DB主从一致性架构优化4种方法
1.半同步复制(等主从同步完成，写主库的请求才返回)
2.强制读主库
3.数据库中间件,记录所有路由到写库的key，在经验主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库
4.缓存记录写key法(与3方法类似)
JMS
JMS的全称是Java Message Service
http://elim.iteye.com/blog/1893038
JMS消息监听器(kafka也有的)
http://elim.iteye.com/blog/1893676
JMS事务管理
http://elim.iteye.com/blog/1983532
P2P模式：每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
Pub/Sub模式：
ActiveMQ工作模式：
http://blog.****.net/qq383264679/article/details/51163144
JMS开发步骤和持久化/非持久化Topic消息
https://www.cnblogs.com/xinhuaxuan/p/6105985.html
Interceptor拦截器与AOP的区别
SpringMVC中使用Interceptor拦截器
它的主要作用是拦截用户的请求并进行相应的处理。比如通过它来进行权限验证，或者是来判断用户是否登陆，或者是像12306 那样子判断当前时间是否是购票时间。
http://elim.iteye.com/blog/1750680
Interceptor拦截器（拦截请求，与过滤器有点类似）与AOP（拦截一个面，不一定是请求，一个方法也可以）
mybatis动态SQL详解
http://www.blogjava.net/stevenjohn/archive/2012/12/25/393451.html
RocketMQ
http://www.jianshu.com/p/453c6e7ff81c
通过同一订单发送到同一个服务器队列，从而保证顺序性
重复性消费，可以
1.保持幂等性，不管来多少条重复消息，最后处理的结果都一样。
2.利用一张日志表来记录已经处理成功的消息的ID，如果新到的消息ID已经在日志表中，那么就不再处理这条消息。
事务消息
1.直接将发消息放到Bob扣款的事务中去，如果发送失败，抛出异常，事务回滚。（业务上实现）
解决activemq多消费者并发处理
http://blog.****.net/Seven__________7/article/details/71854992
activemq有一定机制将队列中的数据交给consumer处理，这个机制就是数据的数量分配，查资料得知，默认是1000，因此，把这个值调小就可以了。
二维码生成工具
MatrixToImageWriter
Bitmatrix
修改请求和响应内容
HttpServletRequestWrapper、HttpServletResponseWrapper
http://blog.****.net/it_man/article/details/7556903
springboot 多环境配置文件的选择
spring.profiles.active
http://www.leftso.com/blog/111.html
maven 多环境配置文件的选择
http://xj84.iteye.com/blog/1135594
https://segmentfault.com/a/1190000003908040
http://zhaoshijie.iteye.com/blog/2094478
页面URL访问统计
DruidWebStatFilter
http://blog.****.net/u011831754/article/details/71631622
解读分库分表中间件Sharding-JDBC
http://blog.****.net/cxboyee/article/details/50672969
如何高效生成趋势有序的全局唯一ID。
类snowflake算法
https://www.cnblogs.com/relucent/p/4955340.html
秒杀系统架构优化思路
1.将请求尽量拦截在系统上游
2.充分利用缓存
浏览器和APP：做限速，每5秒只准请求一次
站点层：按照uid做限速，做页面缓存，返回5S内相同的内容
服务层：按照业务做写请求队列控制流量，做数据缓存，按数据进行后面罗辑的处理，其他返回结柬信息
回仓，未支付的回仓，告诉客户多少分钟后进行重次（如45分钟）
架构设计原则之一是“fail fast”。
做请求队列控制流量
http://shift-alt-ctrl.iteye.com/blog/2315008
easyUI
http://demo.topjui.com/?s=jeasyui
实现线程的阻塞和继续运行（针对当线线程用的），用到做请求队列控制用
LockSupport
http://shift-alt-ctrl.iteye.com/blog/2315008
Semaphore 提供同时访问的数量限制
synchronized、ReentrantLock 是对一个资源并发的控制,单一访问
线程阻塞、唤醒：LockSupport
wait(), notify(), notifyAll()，线程阻塞、唤醒，wait使当前线程等待
同一个账号，一次性发出多个请求.解决为写入标志位
多个账号，一次性发送多个请求.解决为频率高就用验证码或同IP数据限制
多个账号，不同IP发送不同请求.解决为提高帐号的等级要求才可以参加
容量设计
容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等
峰值QPS大概是均值QPS的2.5倍
单机极限QPS，压力测试
互联网架构设计如何进行容量评估：
【步骤一：评估总访问量】 -> 询问业务、产品、运营
【步骤二：评估平均访问量QPS】-> 除以时间，一天算4w秒
【步骤三：评估高峰QPS】 -> 根据业务曲线图来
【步骤四：评估系统、单机极限QPS】 -> 压测很重要
【步骤五：根据线上冗余度回答两个问题】 -> 估计冗余度与线上冗余度差值
单点系统存在的问题
（1）单点系统存在的问题：高可用性问题，性能瓶颈问题
（2）shadow-master是一种常见的解决单点系统可用性问题的方案，keepalive
（3）减少与单点的交互，是存在单点的系统优化的核心方向，常见方法有批量写，客户端缓存
（4）水平扩展也是提升单点系统性能的好方案,DNS解析到不同的nginx外网IP，多个nginx
后台管理界面可以用frame的方式进行不同页面用不同js的层级关系，每个界面都要请求后放到frame中，
用户端就还是用页面路由的方式，以减小页面的请求，frame不适用于用户端(大量用户的前端)
缓存
（1）淘汰缓存是一种通用的缓存处理方式（而不是同步更新）
（2）先淘汰缓存，再写数据库的时序是毋庸置疑的（防止缓存淘汰失败）
（3）服务化是向业务方屏蔽底层数据库与缓存复杂性的一种通用方式
冗余表数据一致性
1.服务层同步写冗余数据
2.服务异步写（引入消息总线）
3.线下异步写(与数据库binlog原理一样)
4.按业务来定先写那个冗余表，影响大的先写
5.线下全量或增量对数据一致性检查
6.用消息对的方式对数据一致性检查（消息对出现的时间一般在3S内）
缓存与数据库一致性保证
1.先淘汰缓存，再写数据库。
主从DB与cache一致性（有一个同步时间问题）
可以用二次异步淘汰的“缓存双淘汰”法来解决缓存与数据库中数据不一致的问题，
（1）timer异步淘汰（本文没有细讲，本质就是起个线程专门异步二次淘汰缓存）
（2）总线异步淘汰
（3）读binlog异步淘汰
DB主从一致性架构优化4种方法
1.半同步复制(等主从同步完成，写主库的请求才返回)
2.强制读主库
3.数据库中间件,记录所有路由到写库的key，在经验主从同步时间窗口内（假设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库
4.缓存记录写key法(与3方法类似)