結合項目
1. spring-shiro 權限問題
使用Shiro Filter 將Shiro和spring整合
<bean id="filterProxy" class="org.apache.shiro.spring.web.ShiroFilterFactoryBean">
<!-- 配置的眾多filter，只要匹配上了前面的一個，后面的都不會進入了 -->
<bean id="shiroMetaSource" class="com.zhaojiaxiu.framework.shiro.ShiroMetaSource">
2.使用redis的好處 原理 代碼
Redis是一個開源的，基於內存的結構化數據存儲媒介，可以作為數據庫、緩存服務或消息服務使用。
Redis支持多種數據結構，包括字符串 string、哈希表 hash、鏈表list、集合set、有序集合sorted set、位圖、Hyperloglogs等。
Redis具備LRU淘汰、事務實現、以及不同級別的硬盤持久化等能力，並且支持副本集和通過Redis Sentinel實現的高可用方案，同時還支持通過Redis Cluster實現的數據自動分片能力。
Redis的主要功能都基於單線程模型實現，也就是說Redis使用一個線程來服務所有的客戶端請求，同時Redis采用了非阻塞式IO，並精細地優化各種命令的算法時間復雜度
前文提到過，Redis采用單線程模型，天然是線程安全的，這使得INCR/DECR命令可以非常便利的實現高並發場景下的精確控制。
代碼：spring-data-redis
/** * Increments the number stored at field in the hash stored at key by increment. * * @param key key * @param field field * @param increment 增量 * @return 操作后的值 */ public Long hIncrBy(final String key, final String field, final Long increment) { return (Long) redisTemplate.<Long>execute((RedisCallback<Long>) connection -> connection.hIncrBy(key.getBytes(), field.getBytes(), increment) ); }
3.使用ActiveMQ的好處,原理 代碼 5.13.0
ActiveMQ持久化節點
3. KahaDB方式
KahaDB是從ActiveMQ 5.4開始默認的持久化插件，也是我們項目現在使用的持久化方式。
KahaDb恢復時間遠遠小於其前身AMQ並且使用更少的數據文件，所以可以完全代替AMQ。
kahaDB的持久化機制同樣是基於日志文件，索引和緩存。
配置方式：
|
1
2
3
4
5
|
<
persistenceAdapter
>
<
kahaDB
directory="${activemq.data}/activemq-data" journalMaxFileLength="16mb"/>
</
persistenceAdapter
>
directory : 指定持久化消息的存儲目錄
journalMaxFileLength : 指定保存消息的日志文件大小，具體根據你的實際應用配置
|
（1）KahaDB主要特性
1、日志形式存儲消息；
2、消息索引以B-Tree結構存儲，可以快速更新；
3、完全支持JMS事務；
4、支持多種恢復機制；
（2）KahaDB的結構
消息存儲在基於文件的數據日志中。如果消息發送成功，變標記為可刪除的。系統會周期性的清除或者歸檔日志文件。
消息文件的位置索引存儲在內存中，這樣能快速定位到。定期將內存中的消息索引保存到metadata store中，避免大量消息未發送時，消息索引占用過多內存空間。
Data logs：
Data logs用於存儲消息日志，消息的全部內容都在Data logs中。
同AMQ一樣，一個Data logs文件大小超過規定的最大值，會新建一個文件。同樣是文件尾部追加，寫入性能很快。
每個消息在Data logs中有計數引用，所以當一個文件里所有的消息都不需要了，系統會自動刪除文件或放入歸檔文件夾。
Metadata cache ：
緩存用於存放在線消費者的消息。如果消費者已經快速的消費完成，那么這些消息就不需要再寫入磁盤了。
Btree索引會根據MessageID創建索引，用於快速的查找消息。這個索引同樣維護持久化訂閱者與Destination的關系，以及每個消費者消費消息的指針。
Metadata store
在db.data文件中保存消息日志中消息的元數據，也是以B-Tree結構存儲的，定時從Metadata cache更新數據。Metadata store中也會備份一些在消息日志中存在的信息，這樣可以讓Broker實例快速啟動。
即便metadata store文件被破壞或者誤刪除了。broker可以讀取Data logs恢復過來，只是速度會相對較慢些。
4.LevelDB方式
從ActiveMQ 5.6版本之后，又推出了LevelDB的持久化引擎。
目前默認的持久化方式仍然是KahaDB，不過LevelDB持久化性能高於KahaDB，可能是以后的趨勢。
在ActiveMQ 5.9版本提供了基於LevelDB和Zookeeper的數據復制方式，用於Master-slave方式的首選數據復制方案。
ActiveMQ服務器掛掉問題解決---盡量不要用非持久化消息，非要用的話，將臨時文件限制盡可能的調大
ActiveMQ丟消息問題解決--用持久化消息，或者非持久化消息及時處理不要堆積，或者啟動事務，啟動事務后，commit()方法會負責任的等待服務器的返回，也就不會關閉連接導致消息丟失了。
ActiveMQ.DLQ死信管理
4.Elasticsreach的好處，原理 分詞器 代碼
5.spring mvc spring spring boot
6.Mybaits 的優點
7.GC
8.四個系統之間的調用關系
9.jsp 和servlet
10.dubbo優點相對其他網絡編程 原理
11.關鍵字 來控制並發操作 volied 和
12.new 對象 在jvm中存儲
11.struts2的過濾器filter 和spring MVC 的攔截器Interceptor
①攔截器是基於Java的反射機制的，而過濾器是基於函數回調。
②攔截器不依賴與servlet容器，過濾器依賴與servlet容器。
③攔截器只能對action請求起作用，而過濾器則可以對幾乎所有的請求起作用。
④攔截器可以訪問action上下文、值棧里的對象，而過濾器不能訪問。
⑤在action的生命周期中，攔截器可以多次被調用，而過濾器只能在容器初始化時被調用一次。
⑥攔截器可以獲取IOC容器中的各個bean，而過濾器就不行，這點很重要，在攔截器里注入一個service，可以調用業務邏輯。
兩者的本質區別：攔截器是基於java的反射機制的，而過濾器是基於函數回調。
從靈活性上說攔截器功能更強大些，Filter能做的事情，他都能做，而且可以在請求前，請求后執行，比較靈活。
Filter主要是針對URL地址做一個編碼的事情、過濾掉沒用的參數、安全校驗（比較泛的，比如登錄不登錄之類），太細的話，還是建議用interceptor。
不過還是根據不同情況選擇合適的。