軟件設計

軟件設計

1. 必定是建立訂單的時候填充market字段，我曾經一度打算在回調的時候再根據回調方來填充Market，可是若是沒有回調呢？Market這樣的標誌性字段必定要依賴於靠譜的操做；
2. 對於重載方法要注意，尤爲套調用的重載方法，對於某些核心校驗必需要放置在裏層方法調用，不然由於重載都是public出去的，均可以被外界調用，若是在外層方法實現校驗，裏層重載方法被外界直接調用，校驗會被跳過；考慮CheckMarket是放在CreateOrder(String encryptedString)仍是CreateOrder(OrderInfo orderInfo)中實現？前者解析加密字符串調用後者，最後想通了是要放在後者中進行校驗；
3. 設計的時候必定要在設定的場景中多走幾遍，這樣作的目的是跳出實現，要把實現放在應用中進行驗證；本質：任何實現都是一個流程的一個環節，其意義在於上下游，而不是實現自己；
4. 獲取玩家信息其實使用舊有的接口便可，可是我卻搞混了玩家信息表和訂單表；分析問題就是要極端：向上謀求大的方向，向下到根（表，字段級別），謀求準確；
5. 騰訊之因此二次驗證是由於：擔憂回調返回信息沒有接收到，沒有扣款；這個機制不一樣於其餘平臺，其餘平臺若是沒有收到，將會續發；騰訊這樣處理實際上是把球拋給了遊戲服務器；
6. OpenId已經修改成String類型真的是百搭啊，做爲衆多市場使用的字段，int的範圍仍是過小了；這個讓我想到了CreateOrder的返回值，對於適配衆多狀況的字段、方法類型必定要考慮百搭的類型；Factory入口參數已經由枚舉改成了字符串類型，由於我發現了一個問題，須要枚舉和顯示字符的互轉，這樣每增長一個市場，同時須要維護枚舉和常量，太不靠譜了；這樣看來單獨一個類裏面封裝常量實際上是比枚舉具備更大的描述能力；CreateOrder之初設計的返回int，這個返回值過小了，包含的信息量遠遠不夠，尤爲是對於支持衆多市場；好比面對騰訊的支付機制，返回的就是一個JSON串，因此對於通用的接口設計返回值的格式要複雜一些，描述能力強一些；
7. 支付市場流程中，支付服務器回調遊戲服務器，其實主要的用意是通知遊戲服務器添加金幣，增長道具；
8. 我已經修改成統一使用BasePaymentInfo做爲參數，這樣的替換大大減小了代碼，以前須要字典對參數進行接收，而後再PaymentService在取出參數進行處理；
9. 其實不少時候一個空的基類，做用就是用於實現開閉原則的閉，BasePaymentInfo裏面什麼都沒有；可是BaiduPaymentInfo以及QihuPayemntInfo都是繼承自它；
10. 前天我在和Steven在談論是否須要把支付拿成一個dll的時候，Steven講到他能夠保證部署的時候不出錯；可是這樣上綱上線有意義嗎，由於是否就是保證修改代碼的人必定可以取到最新的代碼，是否部署的人必定就是Steven？最小的部署就是可以儘可能不要依賴於人的因素，或者儘可能減少人的因素；
11. PaymentService的價值在於對於支付這個領域提供了一層的封裝，對於外界的調用而言只須要知道一個Pay接口就能夠了，而不須要知道還有一個Factory，還有一個Manager；
12. 今天測試發現了一個Bug，更新Bill表以後直接操做更新了PlayerData表，這裏有個問題：若是Bill表查到的數據爲空，是不須要更新後者的，結合另一個Bug，支付失敗了是不須要更新PlayerData的；其實這兩步操做不是代碼關聯，實際上是：兩步操做，牽涉到了兩部分業務（邏輯），這種跨域的操做必定是要有一個分析和校驗過程，是否具有關聯性；這兩個問題提供了一個視角：你再來作項目不要只是看到代碼，而是要抽象到一個更高的角度，從"模塊化"（業務、邏輯）以及全流程來看待開發自己；
13. 建立訂單等操做仍是要放置在BasePaymentManager，而不是Service，由於建立訂單邏輯多是會變得，你須要讓PaymentManager的實現類可以重寫；若是放置在Service裏面就很差處理了；其實開閉原則，講的是對變化開放，對穩定關閉，換句話講，就是對於開放接口是關閉，內部實現是開放，好比對於Service（領域入口）必須是關閉的，須要設計參數都是具備必定的伸縮性，可是對於內部實現，manager是哪一個，應該具備擴展性；
14. 對於接口的伸縮性，好比服務器增長了一種狀況爲，有的客戶端可能須要改代碼，享受新增長的功能，有的客戶端就不須要改代碼，舊有的功能就能夠了，這個時候接口標準是不變的，不須要享受的也不須要改動；保證了請求多樣性；
15. 對於sessionKey的保存最開始打算保存在redis中，可是動物快跑，水滸傳等牙根就沒有Redis，另外，sessionKey是一個很重要的變量（Confirm環節須要拿去和支付服務器作支付確認的），不是那種丟了就丟的重要信息，必定是要保存在數據庫中的；我添加了一個EXT_INFO字段用於存放sessionKey信息；
16. 微信支付Demo中的WXPayData是鍵值對形式（封裝了toXml，toJson等方法），裏面包了一個SortDictionary方法；這種數據結構擴展性很好；很大程度上能夠和空基類相提並論；缺點是沒法進行編譯時報錯；
17. 微信平臺公共平臺的開發由於沒法調用外網；因而我把得到路徑封裝爲一個方法，若是是測試環境（根據配置文件數據），我將會返回一個模擬功能的ashx文件進行數據返回；這樣能夠測試下去了；
18. 在非Web環境下，Controller的session對象爲空；這個時候爲了可以進行單元測試，我設計了一個CaseBase類，這個類會根據配置文件配置，測試環境下（Test工程跑步），就採用內置Diction進行數據保存；正式Web環境下就採用session進行保存；爲了保證全局可訪問，不隨着controller消亡而消失，Diction對象須要聲明爲static變量；
19. 說到了單元測試，我以爲在biz層的設計必定要和前端的神馬（Web技術）技術解耦，就是一個biz框架，提供了那些功能，Web也好remoting也好，仍是Webservice都是能夠直接調用；這個很獨立的第三方；
20. 做爲類庫，能夠考慮返回值爲OperationResult，內部發生異常不要拋出來，讓調用方判斷是拋出仍是過去；
21. 單元測試若是測試的機制和待測試代碼機制同樣也就失去了測試了意義；
22. 梳理清楚業務：1.調用的場景；2.操做了什麼表；3.過得了什麼信息（字段）4.總體流程是怎樣的；
23. 掌握一門技術，要首先搞懂幾個問題：1.這個技術解決了什麼問題；2.優點是什麼，適合什麼場景；3.缺點是什麼，不適合什麼場景；4.提供功能的原理是怎樣的；纔算是瞭解了一門技術；
24. 架構師的世界：一切盡在掌握，對於各個生命週期階段都可以切入和控制；這樣便於擴展，這就須要兩種工具：封裝和隔離（好比MVC很大的好處就是能夠控制view，好比我想要把view緩存，就能夠經過在contrroller裏面作，可是傳統的ASP.Net若是想要對view緩存就不是很直觀；這也是爲何要封裝日誌接口；Session接口；好比serverlet是被tomcat的standwrapper封裝而不是直接使用；歸攏，核心系統套一個殼子隔離和第三方；爲何過時自動刪除redis不多的應用場景，由於刪除不少時候須要業務邏輯判斷以及處理；因此不少時候採用的判斷時間戳，到期了再如何如何；
25. 今天在使用印象筆記發現一個問題，搜索以後，用戶不知道怎麼回到初始狀態，其實咱們作系統設計不少時候都會忽略行爲的回朔，就是任何動做以後，都要讓用戶可以很容易回到某種狀態，至少應該是回到初始狀態，最後還好，在左側菜單找到了"筆記"的圖標，返回了初始頁面，可是這個圖標並不明顯，不論怎樣，evernote仍是考慮到了這一點，搞了一個總回頭的圖標恢復狀態；
26. 需求驅動架構，架構驅動架構，架構驅動測試，測試驅動開發；
27. 測試用例的設計，作到一個方法只測試一個點；
28. 對入口參數校驗真有意義，好比buildcommand方法，若是傳入的ceb的identifier和command不一致，報錯，問題一下清晰了；
29. 剛纔糾結於getdatabuf是否要若是null返回一個new對象，後來發現不須要:就像c++遭人罵就是由於行爲裏面作了太多的事情，職責清晰，儘可能簡單；
30. 框架，是自成體系，只不過有些缺失部分，須要進行填充，而後框架就成爲了系統，系統，是流程，生命週期完備的東西；
31. 開發天天至少應該有39%的時間是在思考，學習；
32. 架構/框架的本質是定義行爲，定義行爲的前提是定義好模塊以及模塊功能，讓這些模塊經過組合可以完成系統的功能；
33. 關係，關係，關係!作設計很重要的一點就是理清楚關係，從session池的處理（鏈接到同端的連個session怎麼區分），到通知參數（多個文件狀況如何通知應用），都在說明，設計就是要捋順對象間關係，面向對象就是構建世界，貌似簡單，可是世界對象間不少關係是隱含的，並不顯式，有些關係能夠忽略不用構建，考慮，可是有些確實要挖掘。
34. 框架思惟，何爲大者，就是看到的點是大的方面，對於系統的理解和開發過程都要放到一個框架思惟來進行設計
35. 什麼是框架？框架就是一種機制，保證某些維度功能的機制（好比開發效率，性能，隔離原則等）;
36. 每當你在設計緩存的時候，考慮數據丟失是否能夠，是否有機制從新獲取，這種機制是否實現;
37. 其實一件事情沒有作完就開始下一件事情，寄託於將來完善，能夠，可是必定是一個成品，而不是概念品，由於，你將來再作這件事情最大的成本就是，你須要從新進行梳理思路。續傳就是這樣，單元測試作完了，沒有結合測試，回過頭來再完善，發現思路全忘了，還要重頭來;
38. 每當你引入一個新的對象，好比任務的臨時ID，都要考慮他的生命週期，以及他的生命週期和別的對象生命週期之間的影響，其次要把生命週期和事件捋順了，好比任務的生命週期是INIT-RECEIVING-REVCOMPLETE-SENDING-SENDCOMPLETE,其中INIT是發生在DATA2Handler，Receving是發生在DATA指令等。
39. 認證，用意就是證實這個用戶存在，受權，就是這個用戶能夠幹這個事情。
40. 都是提供功能，和業務邏輯相關的稱之爲服務，和業務邏輯無關的稱爲基礎設施
41. 作架構設計必定要從重要的，重點的地方設計，不然你的設計極可能就卡在這些地方。好比當時對於斷點續傳考的不全面，直接致使了開發到了後面的問題;
42. switch有一個缺點，容易忘記break, 並且若是多了，其實結構並不清晰，還不如else if;
43. string有一個巨大的問題，就是他實際上是一個弱類型，首先比較容易出錯，是用==仍是用equals，其次複製了一個常量，忘記更名字了，除非運行時測試，不然不自知。這一點是枚舉的好處。
44. PraCommand處理的時候須要知道發送方是否就是目的端。能夠有兩個地方進行處理，目的端發現本身是目的端，則更新PraCommand的isTail字段；第二個地方是接收方來判斷，發送方是否和路由的最後一個設備一致。後來我選擇的是前者，這是由於這樣可以有效的減小判斷；好比做爲轉發端，轉發十個端那麼判斷十次；可是做爲目的端而言其實只須要判斷一次便可。這是一種分壓/分流的機制。
45. 想好了，一鼓作氣寫，減小手敲，增長拷貝，那個寫perl的哥們，c++代碼寫的時候就是絕大多數是拷貝
46. 今天發現了一個方法居然套了五層方法，taskfilestorage裏面居然判斷任務狀態的邏輯在裏面，想一想也是醉了，當初這個類定位就是將任務信息放置到文本文件而已。做爲設計，必定要劃分好類職責，這種實現方法的機制不要超過三層。
47. 傳輸項目作到如今，我最大的心得就是1.控制異常拋出範圍；2.併發控制3.設計的重要性，設計的重要性在於重點難點的設計，全局的考量。
48. 今天發現覺得寫入進度信息到任務文件的異常，致使後續的將文件片進行保存的核心操做都沒有進行處理，在寫代碼的時候必定要將功能進行劃分域，域和域之間不要有本質影響。
49. 必定要使用自定義的異常，而且嘗試拋出他，其實在日誌中很容易發現異常的信息；不處理的異常其實並非壞的事情，吞嚥異常不少時候是隱藏問題。因此經過自定義的異常，並讓他拋出來而且catch打印出來，其實很方便跟蹤問題。
50. 線程必定要考慮到異常處理，不然這個線程將會掛掉，特別是那些定時任務的。
51. 抽象成服務/組件的一個巨大好處就是封裝性，好比斷點續傳，如今就是邏輯散落在各個類中，與之相反，若是有專門的一個或者幾個類處理，那麼就能夠看到續傳類的全貌了。
52. 考慮設計上面的閉環，好比向monitor隊列中放入一個元素就要考慮如何撤掉，哪幾種可能須要撤掉。
53. 對於相似於發送反饋的處理，內部異常就處理掉，不要外拋，不要由於這種無關主業務的操做致使後續操做沒法進行。
54. handler是事件，service是服務，事件組裝服務，服務要擁有比較好的封裝性，好比全部的和斷點續傳相關的操做都要封裝在一個類中。服務封裝1.代碼集中度高，內部高耦合成型；2.好測試，前提保證服務入參簡單，不要讓外部業務污染服務，好比傳入了一個session，就意味着測試的時候須要構建一個session。我忽然以爲本身這種設計和領域驅動有些接近。
55. 我發如今方法體的開始把重要的入參打印出來是一個很好的習慣。
56. 生態，掌握一門技術，其實自己並不難，可貴是掌握它的生態。
57. 傳輸的多線程，異常抖動狀況下仍是有問題。其實最核心的代碼就是在於client.put, client.executeNext兩個方法，分明就應該好好的規劃線路分析如何來處理併發、異常抖動等狀況，可是我卻沒有很好地樹立這個地方，你看到不是一端代碼，一個函數，看到的應該是一個流程，分支，以及這個分支的各個節點。
58. 對象中的屬性和方法的存取也是有權限的，好比對於task的getclient,其實只有發端任務纔有權限，收端任務無權訪問此屬性，不然將會報異常，因此，設計屬性和方法的時候必定要考慮成員權限問題，不管是設計仍是使用。
59. 從新下發，這個策略很好，剛纔我就在糾結髮現一份報沒有有效性怎麼處理，其實就讓運維人員刪除後從新下發就結了。其實不少時候，不要純技術思惟，當發現技術沒法很好的解決一些問題，考慮一下是否能夠採用手工的方式來進行處理；
60. 作項目設計，首先是識別對象，好比三部的項目，包括單位，節點，文件等等，在識別對象的時候同步要把核心屬性識別出來；而後是識別行爲和關係，兩者能夠同步交替進行，OO三劍客以後，項目搞掂了。
61. 不要糾結底層區別，由於區別不大，佔用內存之爭不是頗有意義；
    實例和靜態的根本區別在於概念；面向過程年代，你們都是靜態函數，單例模式是面向對象提出以後的設計模式，若是一個類裏面的函數是和這個類有機的一體的，則是單例，若是類只是做爲容器（好比工具類），那麼就是靜態。
    網上一則比喻很恰當，一我的的胳膊腿，面容是和一我的息息相關的，並且因人而異，這個時候，須要實例，若是說人類所屬的綱目，這些泛華的內容則是靜態的，不由於每一個人的不一樣而不一樣，那麼就是靜態的。
62. 什麼樣的類是單例，什麼樣的類不是呢？若是實例千篇一概，好比配置（文件）類，整個應用程序都是使用一個配置文件，那麼他的映射的ConfigProperties類就應該是單例；若是說不同，好比文件類File，每一個文件都是不一樣的，那麼就是一個實例;
63. 不管是加密機，傳輸機，仍是組裝機，他們最好不要知道任務內容，這樣，每一個機的業務邏輯最純潔，至於任務狀況，由總控來調度任務管理處理，總控只是負責調度，任務只是維護任務信息，各類機只是負責對文件粒度的處理便可。
64. 架構一個很重要的意義在於將複雜問題分解。因此架構的價值在於有效合理識別，歸類和分解。明白此處，系統分析以及架構基本成了。
65. 作開發要想明白一些事情，好比數據的處理，數據要放在內存，仍是放在能夠持久化的緩存，仍是放在數據庫中？這些都是在設計的時候要進行設計的。
    再好比，controller中的返回數據是封裝在個類裏面，仍是要散列的存放；這種數據的組織形式也是要考慮
66. 今天充分體會到了設置類型爲List<T>的實惠了；原本在HiveController中調用historyService.findList()返回的是arrayList；可是後來發現數據結構其實應該是Queue，因而改成了LinkedList，可是這樣的改動其實對於Controller毫無影響。因此這種泛型在封裝向上面有很好的應用，可使用類的函數返回值，本類函數返回值中應用反應，做爲屏蔽封裝部分的複雜性。
67. 前者是非等冪操做；須要進行判斷是否有重複的；可是對於後者則是幾乎是等冪的；不過可能還有一個點須要check就是併發問題，你所改的是否是髒數據。這個在數據庫層面能夠進行判斷；可是若是是修改配置，這個就要看配置是否支持。總之每一個操做以前都要首先想一想是否有須要校驗的地方。安全是大事，其實技術到了高手以後，就是看誰的安全意識和解決方案更合適了。

68. 以前調試結果有點問題，苦於沒有找到緣由；後來看到原來code中這個地方有一個print，一會兒就定位到了是由於loaddataset的問題（書中代碼和github代碼不一致）。這裏說明了輸出日誌文件的重要性。日誌必定要具備其可跟蹤性，可追溯性。

技術

1. 自定義異常很大程度上解決了測試異常的問題；好比如今使用resultCode來判斷錯誤類型，若是使用異常的話徹底能夠利用Exception進行處理；另外.net的ExceptedException真的好弱啊，只能判斷類型，Message都指定不了，難道只能try...catch中增長assert嗎？
2. 多線程開發，對於每個線程而言，代碼都是獨立的，他們不過是按照順序去執行附加的代碼；可是代碼段自己是共享的，這裏系統會爲每一個線程分配本身的參數堆棧，若是是代碼段內部的變量（局部變量），各自堆棧維護，不會有任何問題；操做有交集，可是操做數據都是本身的數據；這個就像過去的合廚作飯同樣，爐子是公用的，可是鍋碗瓢盆，菜果都是本身的，及時彼此作飯有交集，用的都是公用的爐子，空間，可是作出來的都是本身的飯菜；可是，對於共享的變量就不同的：由於他會變，並且不會由於你的操做而變，好比合廚的液化氣，你用完以後，第二次再用存量就會少，由於別人（別的線程）也會用；因此，當你想要對這種公共變量操做的時候，爲了保證操做間原子性，須要爲操做加鎖（鎖上合廚的門）；
3. Buddy描述的關係，並不一點是要好友才使用SFS中的Buddy，可以用Buddy的關係來描述的均可以使用它；
4. 8bit = 1byte；可是位（bit）是計算概念，二進制運算；可是byte是表示概念，一個byte表示能夠容納一個ascii碼值，2個byte能夠表示爲容納一個漢字；
5. 1KB = 1024byte，1GB = 1024KB；bit和byte是8進制，可是B到KB，KB到GB則是10+3E進制（1024）；
6. USE_FLG價格索引後，查詢效率當即提升了；
7. 證書加密的本質：服務器交給客戶端一把鑰匙一把鎖；客戶端將會使用這把鑰匙來打開服務器端發送的"黑匣子"，客戶端會用這把鎖來鎖住"黑匣子"而後寄給服務器端；客戶端一樣也會把一把鑰匙和鎖頭給服務器端；
8. 構建一個性能解決方案列表：insert而不用update；DB遷移到memcache；EF中SaveChange致使性能降低，那麼就採用存儲過程；查詢暱稱致使性能問題，那麼就一次性把ID導入到內存中來；
9. ASCII中有空""，代碼是0，這也是爲何字母排序機制中，"逐位比較"機制中，"aaa"是要小於"aaaa"的緣由，到第四位進行比較的時候，前者是空，ASCII值爲0，後者是"a"，值爲65；備註，0的ASCII值爲48；
10. MIME（Multipurpose Internet Mail Extensions）最初是應用在電子郵件上面，能夠根據MIME信息進行指定應用程序打開傳輸內容；後來這種技術被瀏覽器擴展，早期的瀏覽器是不支持傳輸非ASCII內容的；後來擴展了MIME技術到瀏覽器上面，這樣就能夠經過HTTP協議進行傳輸各類應用類型文件，瀏覽器將會根據MIME信息安排指定的應用程序打開/運行；好比文本文件text/html，pdf文件application/pdf，瀏覽器看到了application/pdf就會使用內嵌的pdf插件進行打開；調查MIME的由頭是application/octet-stream類型，後來這種MIME類型是任意二進制文件；
11. SCSI: Small Computer System Interface,定義了系統和設備交流的標準，好比和硬盤，CD-ROM，另一種經常使用的接口常見的接口是IDE；
12. cpu版本x86是32位，x86_64則是intel爲了兼容AMD的64位指令而設計的；x64則是AMD的架構了；IA-64讓Intel輸慘了；Windows2008原本答應開發基於IA-64的操做系統，結果好久都沒有完成；
13. 負載均衡有兩種，均衡操做，集羣中的讀寫分離就是這種均衡（基於主從服務器）；還有一種是訪問壓力均衡，好比一致性算法，Nginx的IP_Hash等；
14. 設置爲cache-control的max-age以及Expire關鍵字以後，在各個瀏覽器張行爲一致的是經過頁面點擊連接二次連接會緩存頁面，以及新的Tab頁面輸入一樣地址後發送請求，都將不會觸發二次請求，直接用本地緩存文件；對於F5刷新，各個瀏覽器都是每次都從服務器取值；對於IE和firefox而言，在地址欄敲回車不會由於二次請求，chrome依然會進行二次請求；使用firefox以前各類狀況都會向服務器發送請求，後來診斷肯定是由於配置中將緩存空間設置爲0致使；
15. 另一種相關的配置是LastModified，這個指令是response的時候，服務器給客戶端的，這樣下次向一樣的資源發出請求的時候，將能夠直接返回304告知客戶端什麼都沒有改變，這樣就能夠放心大膽的使用客戶端緩存內容了，可是在和業務後臺相關的處理中，須要代碼來判斷是否有改變，須要controller實現LastModified接口，並實現方法進行業務判斷；
16. Ctrl+F5，強制重服務器取出新的內容；其實就是在Request頭中添加了Programa:no-cache；Cache-Control:no-cache；其實你若是使用FF就會發現，若是設置緩存空間爲0，那麼不管你是地址欄敲回車，仍是頁面連接，F12裏面的"網絡"面板都會感應出請求信息，可是一旦你設置了空間，就會在該面板中顯式要你刷新；這就說明了前面的狀況是由於根本就沒有向服務器發出請求，走的本地緩存；
17. Keey-alive容許了客戶端發送請求後，並不立刻斷開Http通道（TCP通道），多個Http請求公用一個TCP通道很大程度上減輕了服務器爲每一個請求建立進程處理的成本(另外還有三次握手，Http是基於TCP的）；由於一個Html，除了頁面元素，還有css，js都是要經過http進行屢次請求完成的；可是keep-alive還有一個缺點，就是若是不能及時釋放將會致使資源浪費；因此Keep-alive通常都是指定timeout和max，max指的是一個通道最多可以接受的請求；timeout指的是斷開鏈接的時長；若是在timeout時長內請求數達到了max上限，將自動斷開鏈接；
18. 在hosts文件中看都有一個註釋掉的::1，這個實際上是表明ipv6地址，ipv6採用128位進行表示，格式爲8個四位16進制組成，1234:5678:90abc:def0:1234:5678:90ab:cdef，爲了兼容Ipv4地址，ipv4地址將被表示爲0000:0000:0000:0000:0000:0000:192.168.0.1（ipv4地址佔據兩段，這意味着ipv4是32位的）；對於前面的六段四位0，能夠簡單表示爲::192.168.0.1；因此你看到的hosts文件中的::1其實就是爲ipv6地址作準備的；
19. "()"在正則表達式中表明模式，前面能夠是一堆^*.，可是真正閃亮登場的確是"模式"，模式表明着真正要匹配的部分，對於replace方法而言，要替換的就是模式部分，若是表達就是模式能夠省略()
20. 在Java裏面當心轉意須要使用\\，由於字符串裏面內容纔是表達式，好比替換掉全部括號裏面內容replaceall("\\([^(]*\\)","")，或者在表達式中先後添加()也能夠，語義更加準確，表示模式
21. 使用filebuffer來封裝hasHMAP<string, queue<commandexchangbuffer>>，可是後來發現這種封裝損失了對於key的遍歷好處，判斷某個是否存在還須要遍歷，而不是contains，十分不優雅；
22. xmlns:xsi是指web.xml遵照xml規範；xsi全名：xml schema instance；
23. xsi:schemaLocation是指具體用到的schema資源, 是命名空間和xsd文檔配對出現，校驗xML是否合法，就是到此得到xsd文件，對節點屬性進行check的；若是你把xml:context刪掉了，spring將會作xML文檔校驗，對於<context>節點就沒法進行解析，編譯將會出錯；
24. spring多作了一點，若是你的xsd文件沒有指定版本號，那麼就不從網址下載，而是從本地的spring的jar文件中，找相應的文件進行處理；避免由於網絡緣由沒法得到xsd文件而啓動失敗
25. spring攔截器，經過mapping以及exclude-mapping，可以指定那些請求須要攔截，那些請求不須要攔截；攔截器須要指定處理bean，對於攔截的請求，交給bean進行處理。
26. 在spring的配置文件頭中指定了不少命名空間；
27. 事務的acid

    原子性，帳戶轉移，A帳戶轉到B帳戶，a轉了10元，B必定會接收到10元，要麼成功，要麼全失敗；

    一致性，A少了10元，B多了10元；

    獨立性，原子操做未完成，B在操做過程當中是不會發現事務過程；

    持久性，對於修改是持續可見的。

    1. 我如今更加發現抽象美妙之處，使用niosession，完美解決tcpsession以及datagRAMsession問題。
    2. 對於有中文的地方，不管是序列成流，仍是反序列化，都須要進行編碼設置。
    3. eclipse引用web工程

a) web工程的deployment assembly中將deploy修改成/，這樣處理是爲了打包的時候外面不須要套一個WEB-INF。

b) 主工程引用該web工程，保證開發時引用工程的類可見，在主工程的deploy assembly中add->project->選擇web工程，默認是將工程打包成war，而後能夠手工修改成jar，這保證了運行是類能被加載。

c) 切記要把被引用的工程要用到的jar包拷貝到主工程的lib下面

1. 調錯於其餘

1. 今天使用log4Net，每條記錄都被打了兩條，個人第一反應是代碼執行了兩邊，可是實際上是由於log4Net配置的問題，配置了兩個logger對象（root以及一個自定義的logger對象）；

1. 狀態，當初不該該圖省事採用commanidentifier，應該從新定義一套定義，語義仍是不太同樣；
   1. 剛纔看到一個問題，總控調用傳輸失敗，看到的異常是初始化失敗，後來才知道，傳輸是經過一個線程起來的，在初始化過程當中報了異常，只是throw了，並無記log，致使後續再調用傳輸類，報初始化錯誤，因此多線程起來的異常必定要記錄，它拋出的異常並無主線程來捕獲；