1. 概述：
任何一行都有自己的軍規, 我想這篇著名的文章就是遊戲服務器程序員的軍規. 也許你認爲遊戲服務器程序員日常並不涉及這樣底層的實現, 而只是去完成策劃提出的需求, 我覺得也有道理, 畢竟這些是我們的工作, 下面的譯文就不太適合你. 但是對於想改進現有系統, 在服務器方面給予更好的技術支持, 那麼你在開始工作之前必須瞭解一些禁忌, 並且給出了一些解決方向上的真知灼見. 把它發在這裏, 供隨時複習. 下面給出一個我閱讀的摘要和感受:
1) 數據拷貝Data Copies – 技巧什麼的
2) 環境切換Context Switches – 理性創建線程
3) 內存分配Memory allocation – 內存池
4) 鎖競爭Lock contention – 沒有好的辦法, 和具體的業務特點以及軟件的設計結構有密切的聯繫
可以看出, 1~3問題通過軟件技術, 分析是比較容易解決的, 並且已經有一些成熟的現成的解決方案和實現. 但是問題4完全不是這個樣子的. 本質上, 前3個問題都比較精確的描述了具體問題, 可以針對性解決. 而第四個問題的麻煩之處是它是一個元問題, 但是真正的問題只有在設計和編碼的時候才由這個元問題製造出來. 除非你已經設計和實現了自己的軟件系統, 否者問題只是存在於理論中. 而引發它出現的原因是你的設計, 這時你想解決這個問題只有推翻你自己的設計, 這通常是不可接受的. 但是現實就是這樣, 這就是爲什麼4號問題是最難解決的.
現在的編程語言都是串行模型, 連編譯器都是認爲:我編譯的源碼肯定是串行的, 以至於它會將
int i = 1;
while (i) { do; }
優化成
while(true) { do; }
呵呵, 除非你用一個volatile來修飾i. 這給編寫併發程序帶來特別特別多的困難. 現在的新語言go,erlang已經開始慢慢在語言層面原生支持併發, 我相信這就像以前的gc一樣, 在以後的不久, 將成爲主流:) 但是上面的4號問題是嵌入在問題域本身的, 它和軟件工程想解決的問題是在一起的, 也就是說對4號問題, 很可能也沒有銀彈.
下面是從網上轉的譯文, 文中重要點用不同的顏色標記出來了.
High-Performance Server Architecture
來源: http://pl.atyp.us/content/tech/servers.html
譯文: http://blog.csdn.net/marising/archive/2010/01/13/5186643.aspx
2. 引言：
本文將與你分享我多年來在服務器開發方面的一些經驗. 對於這裏所說的服務器, 更精確的定義應該是每秒處理大量離散消息或者請求的服務程序, 網絡服務器更符合這種情況, 但並非所有的網絡程序都是嚴格意義上的服務器. 使用”高性能請求處理程序”是一個很糟糕的標題, 爲了敘述起來簡單, 下面將簡稱爲”服務器”.
本文不會涉及到多任務應用程序，在單個程序裏同時處理多個任務現在已經很常見。比如你的瀏覽器可能就在做一些並行處理，但是這類並行程序設計沒有多大挑戰性. 真正的挑戰出現在服務器的架構設計對性能產生制約時，如何通過改善架構來提升系統性能. 對於在擁有上G內存和G赫茲CPU上運行的瀏覽器來說，通過DSL進行多個併發下載任務不會有如此的挑戰性. 這裏，應用的焦點不在於通過吸管小口吮吸，而是如何通過水龍頭大口暢飲，這裏麻煩是如何解決在硬件性能的制約.(作者的意思應該是怎麼通過網絡硬件的改善來增大流量)
一些人可能會對我的某些觀點和建議發出置疑，或者自認爲有更好的方法, 這是無法避免的. 在本文中我不想扮演上帝的角色；這裏所談論的是我自己的一些經驗，這些經驗對我來說, 不僅在提高服務器性能上有效，而且在降低調試困難度和增加系統的可擴展性上也有作用. 但是對某些人的系統可能會有所不同. 如果有其它更適合於你的方法，那實在是很不錯. 但是值得注意的是，對本文中所提出的每一條建議的其它一些可替代方案，我經過實驗得出的結論都是悲觀的. 你自己的小聰明在這些實驗中或許有更好的表現，但是如果因此慫恿我在這裏建議讀者這麼做，可能會引起無辜讀者的反感. 你並不想惹怒讀者，對吧？
本文的其餘部分將主要說明影響服務器性能的四大殺手:
1) 數據拷貝Data Copies -- 技巧什麼的
2) 環境切換Context Switches -- 理性創建線程
3) 內存分配Memory allocation -- 內存池
4) 鎖競爭Lock contention -- 沒有好的辦法, 和具體的業務特 點, 軟件的設計結構有密切的聯繫
在文章結尾部分還會提出其它一些比較重要的因素，但是上面的四點是主要因素. 如果服務器在處理大部分請求時能夠做到沒有數據拷貝，沒有環境切換，沒有內存分配，沒有鎖競爭，那麼我敢保證你的服務器的性能一定很出色.
2.1：數據拷貝Data Copies
本節會有點短，因爲大多數人在數據拷貝上吸取過教訓. 幾乎每個人都知道產生數據拷貝是不對的，這點是顯而易見的，在你的職業生涯中, 你很早就會見識過它；而且遇到過這個問題，因爲10年前就有人開始說這個詞。對我來說確實如此. 現今，幾乎每個大學課程和幾乎所有how-to文檔中都提到了它. 甚至在某些商業宣傳冊中，”零拷貝” 都是個流行用語. 儘管數據拷貝的壞處顯而易見，但是還是會有人忽視它. 因爲產生數據拷貝的代碼常常隱藏很深且帶有僞裝，你知道你所調用的庫或驅動的代碼會進行數據拷貝嗎？答案往往超出想象. 猜猜”程序I/O”在計算機上到底指什麼？哈希函數是僞裝的數據拷貝的例子，它有帶拷貝的內存訪問消耗和更多的計算. 曾經指出哈希算法是一種有效的”拷貝”似乎能夠被避免，但據我所知，有一些非常聰明的人說過要做到這一點是相當困難的. 如果想真正去除數據拷貝，不管是因爲影響了服務器性能，還是想在黑客大會上展示”零複製”技術，你必須自己跟蹤可能發生數據拷貝的所有地方，而不是輕信宣傳.
有一種可以避免數據拷貝的方法是使用buffer的描述符(或者buffer chains的描述符)來取代直接使用buffer指針，每個buffer描述符應該由以下元素組成：
1、一個指向buffer的指針和整個buffer的長度
2、一個指向buffer中真實數據的指針和真實數據的長度，或者長度的偏移
3、以雙向鏈表的形式提供指向其它buffer的指針
4、一個引用計數
現在，代碼可以簡單的在相應的描述符上增加引用計數來代替內存中數據的拷貝. 這種做法在某些條件下表現的相當好，包括在典型的網絡協議棧的操作上，但有些情況下這做法也令人很頭大. 一般來說，在buffer chains的開頭和結尾增加buffer很容易，對整個buffer增加引用計數，以及對buffer chains的即刻釋放也很容易. 在chains的中間增加buffer，一塊一塊的釋放buffer，或者對部分buffer增加引用技術則比較困難. 而分割，組合chains會讓人立馬崩潰.
我不建議在任何情況下都使用這種技術，因爲當你想在鏈上搜索你想要的一個塊時，就不得不遍歷一遍描述符鏈，這甚至比數據拷貝更糟糕. 最適用這種技術地方是在程序中大的數據塊上，這些大數據塊應該按照上面所說的那樣獨立的分配描述符，以避免發生拷貝，也能避免影響服務器其它部分的工作. (大數據塊拷貝很消耗CPU,會影響其它併發線程的運行)
關於數據拷貝最後要指出的是： 在避免數據拷貝時不要走極端. 我看到過太多的代碼爲了避免數據拷貝，最後結果反而比拷貝數據更糟糕，比如產生環境切換或者一個大的I/O請求被分解了. 數據拷貝是昂貴的，但是在避免它時，是收益遞減的(意思是做過頭了，效果反而不好). 爲了除去最後少量的數據拷貝而改變代碼，繼而讓代碼複雜度翻番，不如把時間花在其它方面.
2.2：上下文切換Context Switches
相對於數據拷貝影響的明顯，非常多的人會忽視了上下文切換對性能的影響. 在我的經驗裏，比起數據拷貝，上下文切換是讓高負載應用徹底完蛋的真正殺手. 系統更多的時間都花費在線程切換上，而不是花在真正做有用工作的線程上. 令人驚奇的是, (和數據拷貝相比)在同一個水平上，導致上下文切換原因總是更常見. 引起環境切換的第一個原因往往是活躍線程數比CPU個數多. 隨着活躍線程數相對於CPU個數的增加，上下文切換的次數也在增加，如果你夠幸運，這種增長是線性的，但更常見是指數增長. 這個簡單的事實解釋了爲什麼每個連接一個線程的多線程設計的可伸縮性更差. 對於一個可伸縮性的系統來說，限制活躍線程數少於或等於CPU個數是更有實際意義的方案. 曾經這種方案的一個變種是隻使用一個活躍線程，雖然這種方案避免了環境爭用，同時也避免了鎖，但它不能有效利用多CPU在增加總吞吐量上的價值，因此除非程序無CPU限制(non-CPU-bound), (通常是網絡I/O限制 network-I/O-bound), 應該繼續使用更實際的方案.
一個有適量線程的程序首先要考慮的事情是規劃出如何創建一個線程去管理多連接. 這通常意味着前置一個select/poll/epoll, 異步I/O，信號或者完成端口，而後臺使用一個事件驅動的程序框架。關於哪種前置API是最好的有很多爭論. Dan Kegel的C10K在這個領域是一篇不錯的論文. 個人認爲，select/poll和信號通常是一種醜陋的方案，因此我更傾向於使用AIO或者完成端口，但是實際上它並不會好太多. 也許除了select()，它們都還不錯. 所以不要花太多精力去探索前置系統最外層內部到底發生了什麼.
對於最簡單的多線程事件驅動服務器的概念模型, 其內部有一個請求緩存隊列，客戶端請求被一個或者多個監聽線程獲取後放到隊列裏，然後一個或者多個工作線程從隊列裏面取出請求並處理. 從概念上來說，這是一個很好的模型，有很多用這種方式來實現他們的代碼. 這會產生什麼問題嗎? 引起環境切換的第二個原因是把對請求的處理從一個線程轉移到另一個線程. 有些人甚至把對請求的迴應又切換回最初的線程去做，這真是雪上加霜，因爲每一個請求至少引起了2次環境切換. 把一個請求從監聽線程轉換到成工作線程，又轉換回監聽線程的過程中，使用一種”平滑”的方法來避免環境切換是非常重要的. 此時，是否把連接請求分配到多個線程，或者讓所有線程依次作爲監聽線程來服務每個連接請求，反而不重要了.
即使在將來, 也不可能有辦法知道在服務器中同一時刻會有多少激活線程. 畢竟，每時每刻都可能有請求從任意連接發送過來，一些進行特殊任務的”後臺”線程也會在任意時刻被喚醒. 那麼如果你不知道當前有多少線程是激活的，又怎麼能夠限制激活線程的數量呢？根據我的經驗，最簡單同時也是最有效的方法之一是：用一個老式的帶計數的信號量，每一個線程執行的時候就先持有信號量. 如果信號量已經到了最大值，那些處於監聽模式的線程被喚醒的時候可能會有一次額外的環境切換, (監聽線程被喚醒是因爲有連接請求到來, 此時監聽線程持有信號量時發現信號量已滿,所以即刻休眠), 接着它就會被阻塞在這個信號量上，一旦所有監聽模式的線程都這樣阻塞住了，那麼它們就不會再競爭資源了，直到其中一個線程釋放信號量，這樣環境切換對系統的影響就可以忽略不計. 更主要的是，這種方法使大部分時間處於休眠狀態的線程避免在激活線程數中佔用一個位置，這種方式比其它的替代方案更優雅.
一旦處理請求的過程被分成兩個階段(監聽和工作)，那麼更進一步，這些處理過程在將來被分成更多的階段(更多的線程)就是很自然的事了. 最簡單的情況是一個完整的請求先完成第一步,然後是第二步(比如迴應). 然而實際會更復雜: 一個階段可能產生出兩個不同執行路徑，也可能只是簡單的生成一個應答(例如返回一個緩存的值). 由此每個階段都需要知道下一步該如何做，根據階段分發函數的返回值有三種可能的做法：
1、請求需要被傳遞到另外一個階段（返回一個描述符或者指針）
2、請求已經完成（返回ok）
3、請求被阻塞(返回”請求阻塞”)。這和前面的情況一樣，阻塞到直到別的線程釋放資源
應該注意到在這種模式下，對階段的排隊是在一個線程內完成的，而不是經由兩個線程中完成. 這樣避免不斷把請求放在下一階段的隊列裏，緊接着又從該隊列取出這個請求來執行。這種經由很多活動隊列和鎖的階段很沒必要.
這種把一個複雜的任務分解成多個較小的互相協作的部分的方式，看起來很熟悉，這是因爲這種做法確實很老了. 我的方法，源於CAR在1978年發明的”通信序列化進程” (Communicating Sequential Processes CSP)，它的基礎可以上溯到1963時的Per Brinch Hansen and Matthew Conway–在我出生之前! 然而，當Hoare創造出CSP這個術語的時候，“進程”是從抽象的數學角度而言的，而且，這個CSP術語中的進程和操作系統中同名的那個進程並沒有關係. 依我看來，這種在操作系統提供的單個線程之內，實現類似多線程一樣協同併發工作的CSP的方法，在可擴展性方面讓很多人頭疼.
一個實際的例子是，Matt Welsh的SEDA，這個例子表明分段執行的(stage-execution) 思想朝着一個比較合理的方向發展. SEDA是一個很好的 “server Aarchitecture done right” 的例子，值得把它的特性評論一下：
1. SEDA的批處理傾向於強調一個階段處理多個請求，而我的方式傾向於強調一個請求分成多個階段處理.
2. 在我看來SEDA的一個重大缺陷是給每個階段申請一個獨立的在加載響應階段中線程”後臺”重分配的線程池. 結果，原因1和原因2引起的環境切換仍然很多.
3. 在純技術的研究項目中，在Java中使用SEDA是有用的，然而在實際應用場合，我覺得這種方法很少被選擇.
2.3：內存分配（Memory Allocator）
申請和釋放內存是應用程序中最常見的操作, 因此發明了許多聰明的技巧使得內存的申請效率更高. 然而再聰明的方法也不能彌補這種事實: 在很多場合中，一般的內存分配方法非常沒有效率。所以爲了減少向系統申請內存，我有三個建議.
建議一是使用預分配. 我們都知道由於使用靜態分配而對程序的功能加上人爲限制是一種糟糕的設計. 但是還是有許多其它很不錯的預分配方案. 通常認爲，通過系統一次性分配內存要比分開幾次分配要好，即使這樣做在程序中浪費了某些內存. 如果能夠確定在程序中會有幾項內存使用，在程序啓動時預分配就是一個合理的選擇. 即使不能確定，在開始時爲請求句柄預分配可能需要的所有內存也比在每次需要一點的時候才分配要好. 通過系統一次性連續分配多項內存還能極大減少錯誤處理代碼. 在內存比較緊張時，預分配可能不是一個好的選擇，但是除非面對最極端的系統環境，否則預分配都是一個穩賺不賠的選擇.
建議二是使用一個內存釋放分配的lookaside list(監視列表或者後備列表). 基本的概念是把最近釋放的對象放到鏈表裏而不是真的釋放它，當不久再次需要該對象時，直接從鏈表上取下來用，不用通過系統來分配. 使用lookaside list的一個額外好處是可以避免複雜對象的初始化和清理.
通常，讓lookaside list不受限制的增長，即使在程序空閒時也不釋放佔用的對象是個糟糕的想法. 在避免引入複雜的鎖或競爭情況下，不定期的“清掃”非活躍對象是很有必要的. 一個比較妥當的辦法是,讓lookaside list由兩個可以獨立鎖定的鏈表組成: 一個”新鏈”和一個”舊鏈”.使用時優先從”新”鏈分配，然後最後才依靠”舊”鏈. 對象總是被釋放的”新”鏈上。清除線程則按如下規則運行：
1. 鎖住兩個鏈
2. 保存舊鏈的頭結點
3. 把前一個新鏈掛到舊鏈的前頭
4. 解鎖
5. 在空閒時通過第二步保存的頭結點開始釋放舊鏈的所有對象
使用了這種方式的系統中，對象只有在真的沒用時纔會釋放，釋放至少延時一個清除間隔期(指清除線程的運行間隔)，但同常不會超過兩個間隔期. 清除線程不會和普通線程發生鎖競爭. 理論上來說，同樣的方法也可以應用到請求的多個階段，但目前我還沒有發現有這麼用的.
使用lookaside lists有一個問題是，保持分配對象需要一個鏈表指針(鏈表結點)，這可能會增加內存的使用. 但是即使有這種情況，使用它帶來的好處也能夠遠遠彌補這些額外內存的花銷.
第三條建議與我們還沒有討論的鎖有關係. 先拋開它不說. 即使使用lookaside list,內存分配時的鎖競爭也常常是最大的開銷. 解決方法是使用線程私有的lookasid list, 這樣就可以避免多個線程之間的競爭. 更進一步，每個處理器一個鏈會更好，但這樣只有在非搶先式線程環境下才有用. 基於極端考慮，私有lookaside list甚至可以和一個共用的鏈工作結合起來使用.
2.4：鎖競爭（Lock Contention）
高效率的鎖是非常難規劃的, 以至於我把它稱作卡律布狄斯和斯庫拉(參見附錄). 一方面, 鎖的簡單化(粗粒度鎖)會導致並行處理的串行化, 因而降低了併發的效率和系統可伸縮性; 另一方面, 鎖的複雜化(細粒度鎖)在空間佔用上和操作時的時間消耗上都可能產生對性能的侵蝕. 偏向於粗粒度鎖會有死鎖發生，而偏向於細粒度鎖則會產生競爭. 在這兩者之間，有一個狹小的路徑通向正確性和高效率，但是路在哪裏？
由於鎖傾向於對程序邏輯產生束縛，所以如果要在不影響程序正常工作的基礎上規劃出鎖方案基本是不可能的. 這也就是人們爲什麼憎恨鎖，並且爲自己設計的不可擴展的單線程方案找藉口了.
幾乎我們每個系統中鎖的設計都始於一個”鎖住一切的超級大鎖”，並寄希望於它不會影響性能，當希望落空時(幾乎是必然), 大鎖被分成多個小鎖，然後我們繼續禱告(性能不會受影響)，接着，是重複上面的整個過程(許多小鎖被分成更小的鎖), 直到性能達到可接受的程度. 通常，上面過程的每次重複都回增加大於20%-50%的複雜性和鎖負荷，並減少5%-10%的鎖競爭. 最終結果是取得了適中的效率，但是實際效率的降低是不可避免的. 設計者開始抓狂:”我已經按照書上的指導設計了細粒度鎖，爲什麼系統性能還是很糟糕?”
在我的經驗裏，上面的方法從基礎上來說就不正確. 設想把解決方案當成一座山，優秀的方案表示山頂，糟糕的方案表示山谷. 上面始於”超級鎖”的解決方案就好像被形形色色的山谷，凹溝，小山頭和死衚衕擋在了山峯之外的登山者一樣，是一個典型的糟糕爬山法；從這樣一個地方開始登頂，還不如下山更容易一些。那麼登頂正確的方法是什麼？
首要的事情是爲你程序中的鎖形成一張圖表，有兩個軸：
1、圖表的縱軸表示代碼. 如果你正在應用剔出了分支的階段架構(指前面說的爲請求劃分階段)，你可能已經有這樣一張劃分圖了，就像很多人見過的OSI七層網絡協議架構圖一樣.
2、圖表的水平軸表示數據集. 在請求的每個階段都應該有屬於該階段需要的數據集.
現在，你有了一張網格圖，圖上每個單元格表示一個特定階段需要的特定數據集. 下面是應該遵守的最重要的規則：兩個請求不應該產生競爭，除非它們在同一個階段需要同樣的數據集. 如果你嚴格遵守這個規則，那麼你已經成功了一半.
一旦你定義出了上面那個網格圖，在你的系統中的每種類型的鎖就都可以被標識出來了. 你的下一個目標是確保這些標識出來的鎖儘可能在兩個軸之間均勻的分佈, 這部分工作是和具體應用相關的. 你得像個鑽石切割工一樣，根據你對程序的瞭解，找出請求階段和數據集之間的自然”紋理線”. 有時候它們很容易發現，有時候又很難找出來，此時需要不斷回顧來發現它. 在程序設計時，把代碼分隔成不同階段是很複雜的事情，我也沒有好的建議，但是對於數據集的定義，有一些建議給你：
1、如果你能對請求按順序編號，或者能對請求進行哈希，或者能把請求和事物ID關聯起來，那麼根據這些編號或者ID就能對數據更好的進行分隔.
2、有時，基於數據集的資源最大化利用，把請求動態的分配給數據，相對於依據請求的固有屬性來分配會更有優勢. 就好像現代CPU的多個整數運算單元知道把請求分離一樣.
3、確定每個階段指定的數據集是不一樣的是非常有用的，以便保證一個階段爭奪的數據在另外階段不會爭奪.
如果你在縱向和橫向上把”鎖空間(這裏實際指鎖的分佈)” 分隔了，並且確保了鎖均勻分佈在網格上，那麼恭喜你獲得了一個好方案. 現在你處在了一個好的登山點，打個比喻，你面有了一條通向頂峯的緩坡，但你還沒有到山頂. 現在是時候對鎖競爭進行統計，看看該如何改進了. 以不同的方式分隔階段和數據集，然後統計鎖競爭，直到獲得一個滿意的分隔. 當你做到這個程度的時候，那麼無限風景將呈現在你腳下.
3：其他方面
我已經闡述完了影響性能的四個主要方面. 然而還有一些比較重要的方面需要說一說，大所屬都可歸結於你的平臺或系統環境：
1、你的存儲子系統在大數據讀寫和小數據讀寫，隨即讀寫和順序讀寫方面是如何進行？在預讀和延遲寫入方面做得怎樣？
2、你使用的網絡協議效率如何？是否可以通過修改參數改善性能？是否有類似於TCP_CORK, MSG_PUSH,Nagle-toggling算法的手段來避免小消息產生？
3、你的系統是否支持Scatter-Gather I/O(例如readv/writev)? 使用這些能夠改善性能，也能避免使用緩衝鏈(見第一節數據拷貝的相關敘述)帶來的麻煩. (說明：在dma傳輸數據的過程中，要求源物理地址和目標物理地址必須是連續的. 但在有的計算機體系中，如IA，連續的存儲器地址在物理上不一定是連續的，則dma傳輸要分成多次完成. 如果傳輸完一塊物理連續的數據後發起一次中斷，同時主機進行下一塊物理連續的傳輸，則這種方式即爲block dma方式. scatter/gather方式則不同，它是用一個鏈表描述物理不連續的存儲器，然後把鏈表首地址告訴dma master. dma master傳輸完一塊物理連續的數據後，就不用再發中斷了，而是根據鏈表傳輸下一塊物理連續的數據，最後發起一次中斷. 很顯然 scatter/gather方式比block dma方式效率高)
4、你的系統的頁大小是多少？高速緩存大小是多少？向這些大小邊界進行對起是否有用？系統調用和上下文切換花的代價是多少？
5、你是否知道鎖原語的飢餓現象？你的事件機制有沒有”驚羣”問題?你的喚醒/睡眠機制是否有這樣糟糕的行爲: 當X喚醒了Y, 環境立刻切換到了Y,但是X還有沒完成的工作?
我在這裏考慮的了很多方面，相信你也考慮過. 在特定情況下，應用這裏提到的某些方面可能沒有價值，但能考慮這些因素的影響還是有用的. 如果在系統手冊中，你沒有找到這些方面的說明，那麼就去努力找出答案. 寫一個測試程序來找出答案；不管怎樣，寫這樣的測試代碼都是很好的技巧鍛鍊. 如果你寫的代碼在多個平臺上都運行過，那麼把這些相關的代碼抽象爲一個平臺相關的庫，將來在某個支持這裏提到的某些功能的平臺上，你就贏得了先機.
對你的代碼, “知其所以然”, 弄明白其中高級的操作, 以及在不同條件下的花銷. 這不同於傳統的性能分析, 不是關於具體的實現,而是關乎設計. 低級別的優化永遠是蹩腳設計的最後救命稻草. map注：下面這段文字原文沒有，這是譯者對於翻譯的理解.
附錄：奧德修斯Odysseus，又譯”奧德賽”，神話中伊塔刻島國王，《伊利亞特》和《奧德賽》兩大史詩中的主人公(公元前11世紀到公元前9世紀的希臘史稱作”荷馬時代”. 包括《伊利亞特》和《奧德賽》兩部分的《荷馬史詩》，是古代世界一部著名的傑作). 奧德修斯曾參加過著名的特洛伊戰爭，在戰爭中他以英勇善戰、足智多謀而著稱，爲贏得戰爭的勝利，他設計製造了著名的”特洛伊木馬” (後來在西方成了“爲毀滅敵人而送的禮物”的代名詞). 特洛伊城毀滅後，他在回國途中又經歷了許多風險，荷馬的《奧德賽》就是奧德修斯歷險的記述. “斯庫拉和卡律布狄斯”的故事是其中最驚險、最恐怖的一幕.
相傳，斯庫拉和卡律布狄斯是古希臘神話中的女妖和魔怪，女妖斯庫拉住在意大利和西西里島之間海峽中的一個洞穴裏，她的對面住着另一個妖怪卡律布狄斯. 它們爲害所有過往航海的人. 據荷馬說，女妖斯庫拉長着12只不規則的腳，有6個蛇一樣的脖子，每個脖子上各有一顆可怕的頭，張着血盆大口，每張嘴有3 排毒牙，隨時準備把獵物咬碎. 它們每天在意大利和西西里島之間海峽中興風作浪，航海者在兩個妖怪之間通過是異常危險的，它們時刻在等待着穿過西西里海峽的船舶. 在海峽中間，卡律布狄斯化成一個大旋渦，波濤洶涌、水花飛濺，每天3次從懸崖上奔涌而出，在退落時將通過此處的船隻全部淹沒. 當奧德修斯的船接近卡律布狄斯大旋渦時，它像火爐上的一鍋沸水，波濤滔天，激起漫天雪白的水花. 當潮退時，海水混濁，濤聲如雷，驚天動地. 這時，黑暗泥濘的巖穴一見到底. 正當他們驚恐地注視着這一可怕的景象時，正當舵手小心翼翼地駕駛着船隻從左繞過旋渦時，突然海怪斯庫拉出現在他們面前，她一口叼住了6個同伴. 奧德修斯親眼看見自己的同伴在妖怪的牙齒中間扭動着雙手和雙腳，掙扎了一會兒，他們便被嚼碎，成了血肉模糊的一團. 其餘的人僥倖通過了卡律布狄斯大旋渦和海怪斯庫拉之間的危險的隘口. 後來又歷經種種災難，最後終於回到了故鄉——伊塔刻島.
這個故事在語言學界和翻譯界被廣爲流傳。前蘇聯著名翻譯家巴爾胡達羅夫就曾把”斯庫拉和卡律布狄斯”比作翻譯中”直譯和意譯”. 他說: “形象地說，譯者總是不得不在直譯和意譯之間迂迴應變，猶如在斯庫拉和卡律布狄斯之間曲折前行，以求在這海峽兩岸之間找到一條狹窄然而卻足夠深邃的航道，以便達到理想的目的地——最大限度的等值翻譯.”
德國著名語言學家洪堡特也說過類似的話: “我確信任何翻譯無疑地都是企圖解決不可能解決的任務. 因爲任何一個翻譯家都會碰到一個暗礁而遭到失敗，他們不是由於十分準確地遵守了原文的形式而破壞了譯文語言的特點，就是爲了照顧譯文語言的特點而損壞了原文. 介於兩者之間的做法不僅難於辦到，而且簡直是不可能辦到.”
歷史上長久以來都認爲，翻譯只能選擇兩個極端的一種：或者這種——逐字翻譯(直譯); 或者那種——自由翻譯(意譯). 就好像翻譯中的斯庫拉和卡律布狄斯一樣。如今斯庫拉和卡律布狄斯已成爲表示雙重危險——海怪和旋渦的代名詞，人們常說介於斯庫拉和卡律布狄斯之間, 這就是說：處於兩面受敵的險境，比喻危機四伏，用來喻指譯者在直譯和意譯之間反覆作出抉擇之艱難.