sean hull是一名工作於紐約的技術諮詢顧問，同時也是oracle \u0026amp; open source一書的作者。最近，他在自己的部落格上發布了一篇文章，指出5種「罪過」會對可擴充套件性產生致命影響。他在2023年發布過一篇文章，其中也提到5種罪。加起來，正好是影響可擴充套件性的「十宗罪」。接下來我們一一枚舉，看看到底是哪十宗罪。
\u0026#xd;\n
第一宗：磁碟i/o慢，使用raid5，使用多租戶ebs\u0026#xd;\n
磁碟是所有伺服器的基礎，也是伺服器效能效能的基礎。雖然主記憶體變得越來越大，很多都可以作為快取使用，但是伺服器仍然需要不時從磁碟上讀取資料，從記憶體清出資料。所以磁碟對於效能和可擴充套件性非常重要。
\u0026#xd;\n
raid 5有什麼問題？
\u0026#xd;\n
raid 5是為了用更少磁碟提供更多的空間。常常用於磁碟插槽比較少的伺服器，或者就是因為運維人員不知道它對效能的影響有大。在資料庫伺服器上用會特別不好。
\u0026#xd;\n
解決方案是採用raid 10。每兩個磁碟做映象，然後對它們做stripe操作。即使只有四個硬碟插槽，這麼做也值得。讀寫效能都很好，並且有保護。
\u0026#xd;\n
多租戶的問題是尼瑪怎麼回事？
\u0026#xd;\n
在雲上，可以共享伺服器、網路和磁碟，就像共享某間公寓一樣。amazon的ebs（elastic block storage，彈性塊儲存）是對這個比喻的擴充套件，為你提供儲存網路令人欣喜的靈活性。但是你的瓶頸就是：與其他租戶爭搶同乙個儲存網路。
\u0026#xd;\n
amazon提供的預設伺服器存在這個問題，不過aws解決了這個嚴重的問題，用乙個不太為人熟知但是超級有用的特性——provisioned iops。用它你可以鎖定可靠的磁碟i/o。
\u0026#xd;\n
第二宗：用資料庫處理佇列\u0026#xd;\n
mysql在很多地方都做得很好，但是在處理應用程式排隊方面卻並不理想。你的資料庫中是不是有類似jobs這樣的表，其中有乙個狀態列，包括「queued」、「working」、「completed」這樣的值。如果是，你可能把資料庫來處理應用中的佇列工作了。這樣使用mysql不好，因為會出現鎖的問題，還有查詢下乙個任務時的搜尋和掃瞄任務也會遇到麻煩。
\u0026#xd;\n
建議使用rabbitmq或者amazon的sqs方案，因為這些外部服務更容易擴充套件。
\u0026#xd;\n
第三宗：用資料庫進行全文搜尋\u0026#xd;\n
oracle提供全文搜尋支援，為什麼mysql卻不能用呢？mysql確實有這項功能，但是在很多版本中，只能配合老的myisam儲存引擎使用。最好採用apache solr等經過驗證的搜尋解決方案，它專門用作搜尋，有非常好的庫，開發者可以使用多種現代web語言進行開發，並且非常容易擴充套件。只要在網路中增加伺服器，或者做整體分布即可。
\u0026#xd;\n
對於前沿技術感興趣的同學，mysql 5.6中提供了innodb的崩潰安全和事務儲存引擎。既便如此，還是建議使用外部解決方案，如solr，或者sphinx及mysql sphinx se外掛程式解決。
\u0026#xd;\n
第四宗：每個層次的快取不夠\u0026#xd;\n
快取，快取，及更多的快取。在web伺服器和資料庫之間可以使用memcache或者其他物件快取機制。所有這些小結果集將會主流在記憶體中，等待未來需要它們的web頁面。
\u0026#xd;\n
也要考慮使用varnish這樣的頁面快取，它位於web伺服器之前，不妨將其看成乙個迷你web伺服器，處理很簡單的頁面，但是速度非常快。就像在堵塞的道路上開電單車，讓你的web伺服器加速以完成更複雜的工作。
\u0026#xd;\n
瀏覽器快取也非常重要，但是你無法控制使用者的瀏覽器，也許你可以？當然不是直接控制，但是你可以指導他們快取哪些東西。還要使用合適的過期報頭。讓你的管理員配置apache來支援這一點。
\u0026#xd;\n
第五宗：太多技術欠債\u0026#xd;\n
技術欠債總有一天要還的。這是什麼？探索新的點子，你會搭建乙個原型。當這個原型已經部署給客戶使用之後，要修改就變得更困難，因為某些問題可能有些東西還得掩蓋起來。乙個團隊離開，另外的人接手這個應用，問題變得更複雜。隨時間推移，你的技術債務不斷積累，團隊會花更多時間去維護老的**以及修復bug，開發新功能的時間會越來越少。在某個時候就有必要重寫**了。
\u0026#xd;\n
第六宗：物件關係對映器\u0026#xd;\n
orm很受開發人員的歡迎，但是對於效能專家來說卻不是這樣。為什麼會這樣？原因主要是由於這兩類人看待web應用視角不同。一種是功能開發，以滿足業務需求作為考察的結果。效能和可擴充套件性在這種情況下往往位於較低優先順序。orm能讓開發者更有效率，通過後端的資料儲存將sql的互動難度抽象出來，讓開發者將注意力集中在功能的開發上。
\u0026#xd;\n
從效能角度出發，看到的是另外的場景。如果用orm實現sql查詢，資料庫將無法優化複雜的查詢。而且orm不允許對查詢的簡單調整，拖慢調優過程。
\u0026#xd;\n
第七宗：同步、序列、耦合或鎖定程序\u0026#xd;\n
在web應用裡，鎖相當於現實世界中的交通訊號燈。如果將交通燈換成環形交通樞紐可以顯著提公升流量。因為如果你去乙個交通流量很小的地方，沒有人會在交通燈下做無用的等待。更重要的是：如果有車流量很大，環形樞紐可以讓車輛保持流動。如果需要鎖，最好使用innodb資料表，因為它們能提供粒度更細的行級鎖定，而不是myisam的表級鎖定。
\u0026#xd;\n
要避免出現等待其它節點訊息而無法執行程式的半同步複製。在高事務併發的web應用中，成千上萬的併發會話會導致這種等待的增加。
\u0026#xd;\n
避免任何型別的兩階段提交機制。多階段提交提供了乙個序列入口，讓多個節點投票決定資料應該是什麼樣子，但是它們是擴充套件性的毒藥。最好使用採取最終一致性演算法的技術。
\u0026#xd;\n
第八宗：只有乙份資料庫拷貝\u0026#xd;\n
如果沒有複製機制，那麼你的資料庫就只有乙份。所有的web伺服器只能使用唯一的後端資料儲存，它就會成為漏斗或瓶頸。
\u0026#xd;\n
第九宗：沒有定量衡量標準\u0026#xd;\n
沒有衡量標準是可擴充套件性的一劑毒藥，因為你無法以視覺化方式看見系統中發生了什麼。沒有視覺化的線索，業務部門、開發者和執行團隊很難對擴充套件性方面的問題達成一致。如果團隊認識不到這一點，要讓大家理解：這些簡單的工具可以提供基礎設施的分析。
\u0026#xd;\n
第十宗：缺乏功能標誌\u0026#xd;\n
應用程式如果缺乏功能標誌，會很難實現優雅公升級。如果你的**流量猛增，而你不能施展魔法來擴充套件和提公升流量，有內建的功能標誌，運維團隊就可以在不讓**宕機的前提下，降低伺服器負載。你也得以有更多時間來擴充套件web伺服器或是資料庫，甚至是改進你的應用，允許同時讀寫多個資料庫。
\u0026#xd;\n
不提供這些開關，擴充套件性和可用性就受到了很大限制。
\u0026#xd;\n
影響可擴充套件性的十宗罪
sean hull是一名工作於紐約的技術諮詢顧問，同時也是oracle u0026amp open source一書的作者。最近，他在自己的部落格上發布了一篇文章，指出5種 罪過 會對可擴充套件性產生致命影響。他在2011年發布過一篇文章，其中也提到5種罪。加起來，正好是影響可擴充套件性的 十宗罪 ...
CSS可擴充套件性
今日在寫pc官網的時候，一直對於html css的結構編寫完全按照自己的思維方式，今天把 交給老大的時候，被他指出很多編寫 的錯誤性，比如 結構，標籤的使用，語義化，css的可擴充套件性，由於 主要還是需要做seo優化，所以在標籤使用上也有些不合理之處，給了我一些建議，自己記錄以下 1 在html標...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...