- receive子句的消息匹配模式：如果消息很簡單，使用atom就可以描述的話，沒必要使用tuple，tuple會消耗更多的內(nèi)存，而且減慢了進程的處理速度。
- i()列出當前進程的詳細信息，regs()列出所有注冊進程和端口的詳細信息。ets:i()列出所有ets表的詳細信息。
- atom不會被垃圾回收，因此為所有進程都進行注冊有可能會耗盡內(nèi)存。建議只對長生命周期的進程進行注冊。
- 給pid發(fā)送消息不會有任何錯誤，哪怕該進程不存在；但是，當注冊的進程不存在時，通過注冊名給它發(fā)消息會出錯。
- 進程對接收到的消息不進行處理（匹配）應視為一種bug，因為這些未被處理的消息會不斷的在進程的mailbox里堆積，最后引起內(nèi)存泄露，然后，系統(tǒng)崩潰。mailbox過大的另一個問題是，每次收到新消息，所有的舊消息都要過一遍，從而減緩了進程的處理速度，表現(xiàn)為CPU占用率很高。此外，大容量mailbox的進程還會遲滯那些發(fā)消息給它的進程（因為Erlang runtime為了使大容量mailbox的進程能及時進行處理，它會主動放慢那些給這個進程發(fā)送消息的進程）
但是，丟棄這些消息又會使調(diào)試困難，因此，最好確保在日志中記錄下這些不能處理的消息。
通過優(yōu)化代碼、對OS和Erlang VM精心調(diào)試可以糾正此類問題。
另外同步化發(fā)送消息的進程是一種辦法，發(fā)送進程發(fā)送一個消息然后等待一個確認會減慢maibox的消息增長速度。同步化的副作用是減少了接收處理進程的最大吞吐量，但至少不會使系統(tǒng)當?shù)簟?/li>- Erlang無法完全避免死鎖，例如進程Ａ同步調(diào)用進程Ｂ（Ａ給Ｂ發(fā)送消息，然后等待Ｂ返回響應消息），后者（Ｂ）又同步調(diào)用進程A。
- 進程的優(yōu)先級可以通過調(diào)用process_flag(priority, Priority)進行調(diào)整，但是不鼓勵調(diào)整進程的優(yōu)先級，甚至應該完全禁止使用。
- 進程間的聯(lián)系有兩種，一種是雙向的，即link；一種是單向的，即monitor。前者建立的聯(lián)系是永久的，后者是臨時的。前者只能給存在的進程建立聯(lián)系，后者可以監(jiān)視不存在的進程（當然會立即收到一個{'DOWN'...,noproc}消息）。顯然后者適合用在不對稱關系的進程中，例如client-server
- 解除對進程的監(jiān)視最好調(diào)用erlang:demonitor(Reference, [flush])，因為demonitor調(diào)用之前監(jiān)視的進程可能就DOWN掉了。
- 任一進程非正常退出，會給其link的進程集發(fā)出exit信號，exit信號將像多米諾骨牌一樣傳遞出去（每張牌就是一個進程，倒掉代表進程被結(jié)束）。可以理解成：調(diào)用process_flag(trap_exit,true)后，進程將收到的其它進程exit信息轉(zhuǎn)換成{'EXIT', Pid, Reason}消息，從而制止了多米諾骨牌的繼續(xù)倒掉；
- 進程的正常結(jié)束不會引發(fā)關注：進程正常退出時，也會給它的直接link set發(fā)送exit信號，但這個正常退出信號不會進一步的傳播下去，也就是說正常退出信號不會引發(fā)多米諾骨牌的倒塌。（設置了trap_exit標志的進程會將這個exit信號轉(zhuǎn)換成消息{'EXIT',Pid,normal}）。
- 兩個在不同計算機上的link進程，如果它們之間的網(wǎng)絡連接斷掉了，會收到{'EXIT', Pid, noconnection}的消息
- 大型的Erlang系統(tǒng)中不應該有孤兒進程，也就是說所有的進程都要連接在一棵巨大的supervision樹上。孤兒進程有兩個問題，首先不容易發(fā)現(xiàn)bug：當這些進程因bug當?shù)魰r，根本無從知曉。另一個問題是“進程泄漏”，孤兒進程因為某種原因掛了起來，它會一直掛著，隨著越來越多的進程掛起，這些不斷積累的孤兒進程終將耗盡內(nèi)存。
- supervisor進程的唯一任務就是啟動子進程并監(jiān)視之。supervisor設置成trap_exit，并link到所有子進程。
- Erlang的在線升級，分兩種情況。第一種情況是模塊A在進程中運行，A會調(diào)用模塊B的函數(shù)，運行A模塊的進程會維持一個到模塊B的最新版本的鏈接（link），在模塊B重載后，進程中模塊B的鏈接（link）會切換到最新版本，這樣，模塊A以后會自動調(diào)用更新后的函數(shù)。第二種情況是模塊A本身的升級，這種正在進程中運行的模塊的升級要復雜一些，取決于模塊中函數(shù)的調(diào)用方式：是直接調(diào)用，還是fully qualified function call調(diào)用（指B:fun1()這樣的調(diào)用），如果是直接調(diào)用，在模塊重載后，還是維持舊版本的模塊，而 fully qualified函數(shù)調(diào)用將會立即切換到最新版本的函數(shù)。
- Erlang運行時只維持兩個版本的模塊代碼，因此在第2次模塊升級后，最老版本的模塊會被移除，如果有進程仍然運行最老版本的模塊，這些進程將隨著最老版本模塊的移除而被終止（killed）。
- 有三種裝載模塊的方法。第一種是直接調(diào)用模塊中的函數(shù)，此時一個叫code server的進程（它是Erlang kernel的一部分）將會搜索相應的beam文件，然后裝載之；第二種是編譯該模塊（相應的函數(shù)是compile:file(Module)）后會自動裝載編譯好的模塊，在shell中是通過命令c(Module)；第三章方式是顯式的裝載模塊，通過調(diào)用code:load_file(Module)轉(zhuǎn)載指定的模塊，在本機上可以通過命令l(Module)裝載模塊，在網(wǎng)絡中可以通過命令nl(Module)將模塊裝載到各個節(jié)點上。
- Erlang運行時，同一個模塊至多維持有兩個：舊的和當前的。當又有新的版本裝載進來，舊的那個會被清除，當前的變成舊的，剛裝載上的成為當前的。其中舊的、當前的模塊與該模塊實際版本無關，而與裝載的時間順序有關（可能先裝載一個最新版本的模塊，之后又裝載老版本的模塊，這種情況下先裝載的模塊是舊的，后裝載的模塊是當前的）。
- shell中按tab鍵會顯示所有已裝載的模塊。
- 調(diào)用code:is_loaded(Module)判斷模塊是否已裝載。shell中通過tab鍵補全特性判斷模塊是否已裝載。
- code server的主要任務是動態(tài)的裝載和清除模塊。通過code模塊中的函數(shù)可以操作code server，進而對系統(tǒng)代碼庫進行管理和配置。
- code search path是code server裝載模塊是的搜索路徑，缺省包括當前路徑，以及所有庫應用的路徑。通過code:get_path()查看。
- Erlang根目錄：即Erlang安裝目錄，所有庫應用都在根目錄的lib目錄下，通過code:root_dir()可以查看根目錄位置。
- 熱升級面臨的幾個問題：升級步驟原子化；向后兼容以備升級失敗；分布式環(huán)境中升級的同步化。SASL應用庫提供了一些熱升級的工具。
- 最簡單的熱升級是重載模塊即可。前提條件是升級不會修改已存在的loop data。
- 既然函數(shù)也是一種數(shù)據(jù)，那么顯然，它也可以是tuple的一部分、record的一部分，也可以作為消息進行發(fā)送。當然，作為其它函數(shù)的返回值也就沒什么奇怪的，這樣就可以在運行時動態(tài)的創(chuàng)建函數(shù)了。
- reference數(shù)據(jù)：在分布式環(huán)境中reference數(shù)據(jù)提供了一個跨進程的唯一標識（tag），它主要用于進行比較，多于消息傳遞有關。
- 用變量綁定已定義在模塊中的函數(shù)：Fun1 = fun Module:Function/Arity
- 將函數(shù)傳遞給遠程節(jié)點時，顯然，函數(shù)中調(diào)用的那些模塊必須也在遠程節(jié)點的code search path中。
- 一個binary是一塊無類型的內(nèi)存的引用。最初被Erlang用來通過網(wǎng)絡加載代碼，隨后就應用在基于socket的通訊中。
- ets的match操作有可能會損害Erlang系統(tǒng)的實時性：這是因為所有的match操作都是作為BIF實現(xiàn)的，而BIF的執(zhí)行具有原子性，當對較大的ets表進行match操作時要遍歷完整個ets表，這就會堵塞其它進程。要避免此類問題最好用first、next遍歷ets表，這樣做也許會更慢，但至少不會損害系統(tǒng)的實時性。
- 用ets存儲record數(shù)據(jù)要指定key位置，因為作為record的tuple第一個元素總是相同的。
- 一個Erlang節(jié)點是指運行中的Erlang運行時系統(tǒng)。一個alive的Erlang節(jié)點是指“能夠”與其它節(jié)點通訊的節(jié)點，alive節(jié)點必須有名字。調(diào)用erlang:is_alive()判斷當前節(jié)點是否alive。net_kernel模塊提供了控制Erlang節(jié)點alive的函數(shù)。
- alive的Erlang節(jié)點名字有兩種：短名(short name)和長名（long name），短名節(jié)點只能與短名節(jié)點通訊，長名節(jié)點只能與長名節(jié)點通訊。
- Erlang系統(tǒng)的安全理念是：要么完全信任你，要么完全不信任你。因此互聯(lián)的遠程Erlang節(jié)點擁有本地節(jié)點的所有訪問權限。對于互聯(lián)網(wǎng)上分布的Erlang節(jié)點，可以通過SSL加強安全性。
- 節(jié)點間的安全是通過cookie控制的，每個節(jié)點持有一個被稱為secret cookie的atom，持相同cookie的節(jié)點間才能進行通信。（home目錄下有個“.erlang.cookie”文件，其內(nèi)容為缺省cookie值。）另外，通過臨時設置cookie可以讓擁有不同cookie的節(jié)點間互通。
- 分布式節(jié)點間的互聯(lián)是通過每個節(jié)點上的net_kernel進程實現(xiàn)的，進程的遠程啟動也是net_kernel負責。net_kernel進程通過cookie進行安全授權。因此用戶可以通過修改net_kernel定制自己的安全授權機制。
- 對于有太多Erlang節(jié)點的分布式系統(tǒng)，一個問題是會有太多的TCP/IP連接，如果有N個節(jié)點，這些階段彼此聯(lián)通，會有N * (N - 1) / 2個TCP/IP連接。解決辦法是hidden node。
- 通過node(hidden)或node(connected)查看hidden nodes
- hidden node的一個用法是作為“網(wǎng)關”將許多小的分布式機群連接起來。另一個用法是用來做維護，它不會影響流量。
- 通用的消息發(fā)送格式是Pid ! Message，給遠程注冊進程發(fā)消息是：{register_name, node} ! Message
- receive的timeout一個麻煩的地方是可能超時后消息又到了，這時消息就會堆積在接收進程的mailbox中，在該進程又一次進入消息接收時，可能處理的是這些超時后堆積的消息，因此進行消息接收之前最好flush一下進程的mailbox。
- monitor_node(RemoteNode, true)用于監(jiān)控遠程節(jié)點，當被監(jiān)控的遠程節(jié)點當?shù)魰r監(jiān)控進程會收到{nodedown, RemoteNode}消息。
- 查詢某個進程（Pid）、某個引用（Reference）或者某個端口（Port）在哪個節(jié)點上，可以使用BIF函數(shù)node(Arg)。
- epmd是Erlang port mapper deamon的縮寫，這是一個操作系統(tǒng)級的守護進程，是Erlang運行時系統(tǒng)的一部分。不管運行了多少Erlang節(jié)點，每個計算機只運行一個epmd，它隨Erlang節(jié)點的第一次啟動而啟動，不隨Erlang節(jié)點的結(jié)束而結(jié)束。epmd負責監(jiān)聽4369端口上的連接請求，然后將其映射給相應節(jié)點的監(jiān)聽端口。
- epmd可以作為shell命令單獨啟動，該命令還帶若干參數(shù)，可以通過 epmd -help查看。例如可以查看所有erlang節(jié)點的占用端口。
- epmd的一個重要用處是通過參數(shù)delay_accept和delay_write可以模擬網(wǎng)絡繁忙的情況，便于測試。
- 程序員編寫的OTP應用（OTP application）是構成Erlang系統(tǒng)的磚石，它在運行時的進程組成一個supervision樹。OTP應用本身是一種OTP behavior。
posted on 2017-01-11 17:23
思月行云 閱讀(224)
評論(0) 編輯 收藏 引用 所屬分類:
Erlang