天学到的技术点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.csdn.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扣款的事务中去，如果发送失败，抛出异常，事务回滚。（业务上实现）
http://blog.csdn.net/lovesomnus/article/details/51776942


解决activemq多消费者并发处理
http://blog.csdn.net/Seven__________7/article/details/71854992
activemq有一定机制将队列中的数据交给consumer处理，这个机制就是数据的数量分配，查资料得知，默认是1000，因此，把这个值调小就可以了。


二维码生成工具
MatrixToImageWriter
Bitmatrix
使用Zxing生成二维码，以及在生成的二维码中添加logo:
http://mygirl1314520.iteye.com/blog/1912109


前端生成二维码
jquery.qrcode
http://www.360doc.com/content/16/0426/10/26839592_553877055.shtml
http://www.jb51.net/article/121537.htm
http://happyqing.iteye.com/blog/2294628
https://www.cnblogs.com/songyz/p/7490562.html





修改请求和响应内容
HttpServletRequestWrapper、HttpServletResponseWrapper
http://blog.csdn.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
http://blog.csdn.net/fengchao2016/article/details/72726101



页面URL访问统计
DruidWebStatFilter
http://blog.csdn.net/u011831754/article/details/71631622



解读分库分表中间件Sharding-JDBC
http://blog.csdn.net/cxboyee/article/details/50672969



如何高效生成趋势有序的全局唯一ID。
类snowflake算法
https://www.cnblogs.com/relucent/p/4955340.html



秒杀系统架构优化思路
1.将请求尽量拦截在系统上游
2.充分利用缓存
浏览器和APP：做限速，每5秒只准请求一次
站点层：按照uid做限速，做页面缓存，返回5S内相同的内容
服务层：按照业务做写请求队列控制流量，做数据缓存，按数据进行后面罗辑的处理，其他返回结柬信息

回仓，未支付的回仓，告诉客户多少分钟后进行重次（如45分钟）

架构设计原则之一是“fail fast”。


做请求队列控制流量(LockSupport)
http://shift-alt-ctrl.iteye.com/blog/2315008

LinkedBlockingQueue、信号量(指定数据库能接受的瓶颈)(能得到信号量或能入队列的继续执行，不能的返回结束信息)


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方法类似)


CAS SSO 单点登陆原理
https://www.cnblogs.com/lihuidu/p/6495247.html
http://blog.csdn.net/yuwenruli/article/details/6620947



通过请求队列的方式来缓解高并发抢购
https://www.cnblogs.com/XiaoyangBoke/p/6701780.html


超高并发的无锁缓存
在【超高并发】，【写多读少】，【定长value】的【业务缓存】场景下：
1）可以通过水平拆分来降低锁冲突
2）可以通过Map转Array的方式来最小化锁冲突，一条记录一个锁
3）可以把锁去掉，最大化并发，但带来的数据完整性的破坏
4）可以通过签名的方式保证数据的完整性，实现无锁缓存


//如果不同模块的数据要进行合并，但又不想用join(后面可能分库),又不想的一个个查，可以增加in查询接口再进行数据合并


操作日志可以使用消息队列的方式来实现，不用每次都进行数据库的访问


springboot jpa 连接多个数据库的例子
https://github.com/itguang/gitbook-smile/tree/master/springboot-multi-datasource



“配置”架构演进
1.配置私藏,上游调用下游，每个上游都有一个专属的私有配置文件，记录被调用下游的每个节点配置信息。
2.全局配置
3.文件监控组件FileMonitor,动态连接池组件DynamicConnectionPool
4.配置中心,服务化


高可用性
服务集群（nginx,RPC），数据库主主同步，keepalive备机,前端CDN，接入层DNS


数据安全
备份，异地灾备，


高并发
缓存、快速失效、服务集群、队列处理、消息队列、数据做索引,分库分表,静态页面的尽量静态、存储过程、批量读取、缓存延时修改（一定时间再写数据库）、


一致性
事务，消息队列、后端数据校验、缓存锁、CAS


实时性（高性能）
缓存、快速失效、带宽、CPU性能、服务集群、不必要的处理用消息队列后期处理、


高可扩展性


重要数据可以在业务中进行前后数据的更改进行记录


10万定时任务实现
1.一个定时器，论询查询每任务是否超时,效率低
2.每个任务一个定时器，消耗资源多
3.定时环形队列，环形队列上记录每个任务ID，这样一个定时器就可以实现知道那些任务时间到达设定的时间或超时了
http://mp.weixin.qq.com/s/mvFwjgxliwx808Hn_9ruEA


spring boot 集成ActiveMQ
http://blog.csdn.net/q672746525/article/details/79295925



提高ActiveMQ工作性能
http://blog.csdn.net/yinwenjie/article/details/50991443



树状有层次关系的，又要显示层次关系的，可以在关联层次时以“，”分开各树状态层次的关系，这样既方便进行层级筛选，又方便得到层级的名字层次关系



接口测试工具
jmeter



后台管理接口因用户人数少，并发小，可忍耐性高，可以通过多查几次数据库进行数据组合返回前端，

用户系统并发高，用户量大，不谊多次查数据库，可以用多级缓存的方法进行数据的组合，不要找请求都放到数据库进行处理。

对于用户系统的搜索可以通过集群（数据库主从多库）应对高并发，对于搜索用户等一会还是可以接受的，对于集合里还要其他数据组成可以使用IN查询再通过代码进行组合来减少数据库查询的次数(减少数据库压力和响应时间)。


controler获取绝对路径的方法：
this.getClass().getClassLoader().getResource("/").getPath(); 此处为classes目录, 往上一层可以用getResource("/../")，
直接指向文件名getResource("/../xxx.xxx")


行业、供应商、品牌、分类之间的关系结构
1.行业单独进行管理
2.品牌与行业进行（一个品牌对应多个行业的方式进行（单独一个表存放关系））
3.供应商与品牌进行关联（1对多）（从而就与行业进行了关联，出可以单独与行业进行关联（1对多））
4.分类与行业进行关系（每个行业会有不同的分类）


https://www.cnblogs.com/ityouknow/p/6120544.html
springboot RabbitMQ详解


java读取数据库表的相关信息


Ehcache


zTree 是一个依靠 jQuery 实现的多功能 “树插件”。优异的性能、灵活的配置、多种功能的组合是 zTree 最大优点。(后端只要返回list,前端进行树处理的插件)



mybatis 如果返回结果为map(字段（key）,字段值(value)),pageInfo也支持的。返回MAP可以不用写相关的requestMap,但可读性和理解性就没那么好