1.先看現成的，可以直接用的

*如果是代碼，直接先跑demo，然後再研究

*如果有現成的或者之前已經寫好的功能，先去看他們如何實現的，再添加

++++++++++++++待整理+++++++++++++++++++++

1.webxml的配置文件詳解
2.DES是什麽，如何加密
3.token是什麽，如何使用
4.數據從前臺輸入到後臺db然後再反向的傳遞過程
5.三個web服務器的端口/路徑/log配置
6.session和cookie如何儲存和生命周期
7.JVM調優
8.HTTP協議
9.TCP/IP協議
10.序列化
11.枚舉
12.web服務器配置
13.servlet接口
14.tomcat加載過程
15.類加載器
16.雙親委派模型
17.gc
18.sti
19.jvm
20.rmi
21.token過期異常
22.redis和memcache在db更改的時候同步更改
23.在jmeter測試mysql的時候，線程消耗在什麽地方
jsp controller獲取數據的時間
servlet獲取數據的時間
從mysql中查詢到數據的時間

代碼不超過50行，低耦合，高內聚，復用性，壓縮性
嚴於律己寬以待人
高內聚：模塊功能專一性高，獨立性強
低耦合：模塊之間聯系盡量少
聯系緊密
在模塊劃分時，要遵循“一個模塊，一個功能”的原則，盡可能使模塊達到功能內聚

高內聚，低耦合的系統有什麽好處呢？事實上，短期來看，並沒有很明顯的好處，甚至短期內會影響系統的開發進度，因為高內聚，低耦合的系統對開發設計人員提出了更高的要求。高內聚，低耦合的好處體現在系統持續發展的過程中，高內聚，低耦合的系統具有更好的重用性，維護性，擴展性，可以更高效的完成系統的維護開發，持續的支持業務的發展，而不會成為業務發展的障礙。

第一 查找知識的能力
第二 描述問題的能力
第三 總結收獲的能力
第四 解決問題的能力
第五 構建技能的能力
第五 遵守規範的能力

“對緩存來說，最關鍵的設計就在於失效策略是什麽。”大神鎮定的看著我。

不同的應用場景，對於緩存的要求不一樣，對實時性的要求也不一樣。榜單這種一天更新一次的，每天晚上定時生成一次就好了。後臺更新，但是要註意，一定要直接生成，直接切換，不能讓前端用戶訪問的時候，再去生成。
對於名字這種東西，用戶改完之後，必須立刻更新緩存，包括本地緩存和遠程緩存。

根據不同的應用需要，去設計不同的策略，同時把這些場景規範化，成為一整個團隊都要去遵循的標準？

每一個技術框架的選擇，都經過討論，驗證，測試，最終在全團隊裏推行。

這是否也是架構師的職責？這個架構師太厲害了，他需要從前到後都要懂，他需要制定關鍵的技術細節，他需要給出最佳實踐，他需要了解業界所有流行的解決方案，他需要去猜測Facebook怎麽解決問題的，Twitter怎麽解決問題的，Google怎麽解決問題的，這些解決方案可不可以拿過來，也同樣適用於我們自己的場景。

他需要精通分布式，Nginx或者是F5，微服務，緩存，持久化，消息隊列，他需要熟悉所有這些技術細節裏的最常用的解決方案，不能有遺漏，也不可以過度設計，他決定的不是他一個人喜歡的風格，他決定的就是整個團隊，在項目死亡之前都必須遵循的規範，現在的團隊成員，和未來的團隊成員，都必須遵循的體系，而且，如果在未來，這些架構體系有不合理的地方，那就麻煩大了。

完整的看過TCP/IP協議詳解

怎樣快速提高自己