算起來接觸erlang 快四個月來，從零開始看書寫erlang**、修改rabbitmq、業務開發、系統調優，總算是有點入門了。
最難受的是邊學邊修改rabbitmq，難受只是暫時的，憋過去就海闊天空，最後提交修改2000+行**。
說到坑都是自己技術不過關造成，erlang 設計與一般語言很大不同，雖然簡單但還是有不少需要注意點；erlang 是一門非常成熟語言，otp 也特別穩定，不過要想用好，很不容易。
列舉遇到的注意點：
1. 學習資料少
書：《programing erlang》erlang 作者寫的，通俗簡單 嗯 真的很簡單。。看一遍就夠寫得都差不多
官方文件： 不夠詳細？湊合看吧，好歹有
部落格推薦：（建議有空將他們部落格通讀一遍，助你繞過前人走過的彎路）
（強推）
2. error_logger
這是個坑貨， 而且預設crashlog 用這玩意兒記，一旦程序批量crash，因為內部receive-match 寫磁碟方式，越來越慢。
可以選用lager，不過lager 在message_queue_len 超過指定值(50)後採用同步方式，內部依然是receive-match 寫磁碟 方式寫磁碟，
建議實現自己的lager_backend，通過cast 到獨立 gen_server2 寫磁碟，或者cast 到網路寫到日誌伺服器上去
3. gen_server receive-match 問題
避免在熱點gen_server 中使用receive-match 方式，或者都使用如rabbitmq 中的gen_server2，一定要防止在message_queue_len可能
比較大的程序中做recieve-match，error_logger就存在這個問題。
4. 熱點程序
erlang 是公平排程，熱點程序在負載稍高時，就會沒機會得到處理，注意設定priority high
5. 單程序處理瓶頸
erlang 中因為程序無法共享資料，往往使用單個gen_server 完成共享邏輯，但erlang cpu計算是很低效的，往往但程序無法完成業務處理。
這個時候需要拆分到多個程序處理，如:server_1, server_2 .... 。
6. ets
4、5 另乙個解決方案是使用ets，ets 可以作為全域性表，所有程序都可以讀寫，不存在熱點程序，而且減少了程序訊息互動成本，效率要高很多。
但是，ets 是表結構，能夠適合的場景很少，能用那就盡量多使用吧。
7. rpc:call
成本較大：一次呼叫有3次網路往返
服務端單程序：服務端有rex 程序處理，容易產生瓶頸，測試最多處理 10w/s 訊息
如有必要盡量多使用 pid ! msg - receive 方式
8. gen_server:call timeout
timeout 是給call 方返還的，而實際處理一定會被處理，而且reply 也會在timeout 後發回message_queue，要注意。。
9. pid ! msg
pid 不存在時，訊息丟失， gen_cast 也一樣；就算is_process_alive 判斷也會存在競態，所有是無法判斷是否send sucess ，只能reply 確認
10. 依賴supervisor
erlang 設計模式，一般不怎麼處理異常，非常態錯誤依賴supervisor 重啟。 但如果gen_server 存在資料，重啟瞬間 就會丟失資料。
初用jekins遇到的小問題
1 安裝好jekins後，新建第乙個自動化測試job 報no such file or directory錯誤 原因為在job 配置 構建 命令處輸入的命令為，這樣輸入識別不到檔案 python c users administrator pycharmprojects untitled mylog...
用msn時遇到的問題
1 提示 服務暫時不可用 還說是防火牆阻止了連線 還有個號 80048883 圖 msn 登陸失敗.jpg 2 疑難問題解答程式，提示 閘道器顯示為離線 圖 msn message疑難解答對話方塊.jpg 3 選項 連線 連線狀態 提示 沒有連線到 net message web service 圖...
rabbitmq安裝時遇到的問題總結
1 啟動指令碼中不增加export home opt midware rabbitmq時，報錯 rabbitmq server erlexec home must be set 修改辦法 增加 export home var joe rabbitmq 注意 var joe rabbitmq是我的安裝...