集群的設計思路和常用的技術
1.目前常用的web伺服器有apache,nginx,lighttpd,iis,tomcat等等。
nginx：節省資源、在處理高併發請求時通常可以是apache5-10倍。
2.負載均衡：**請求到後端伺服器。是解決高併發量的方法。只要用了集群，那麼肯定會用負載均衡。原理如下：
軟體：優點：免費 。有兩種軟體，一種工作在網路的第四層，一種是第七層。
nginx（七層）：只能做web[http協議]伺服器負載均衡、使用簡單。
硬體：優點：穩定、效能非常好 缺點：**昂貴（大型網遊伺服器需要使用）。
流程：開始客戶端請求www.34.com，由於網域名稱是繫結到負載均衡伺服器的，因此負載均衡伺服器會接收到請求並且通過一定的配置策略(最典型的配置策略，輪詢)**請求到後端伺服器。然後web後端伺服器返回資料有兩種方式，一種是直接返回給客戶端，另一種是返回給負載均衡，再由負載均衡返回給客戶端。前者有兩個問題：成本高，因為web伺服器要把資料返回給客戶端，首先得上外網，那麼就得有ip位址，ip位址要買。同時也不安全，因為web伺服器暴露在外網上了就很容易受到攻擊。後者問題是：所有返回的資料都需要經過負載均衡伺服器，該伺服器的處理能力會成為瓶頸。一般採用後者的方案，只要每個負載均衡伺服器掛的集群不要太大就行。除此之外，負載均衡還需要對web伺服器做健康檢查，一旦向某一台web伺服器**請求超過3次失敗，則判定該web伺服器壞了。
3.反向**（快取伺服器、網頁加速器）：**中的靜態的內容可以用反向**。
原理：開始客戶端請求www.34.com，負載均衡伺服器接收請求並**到反向**伺服器，該伺服器會先在本地的記憶體裡找有沒有快取資料如果有就直接返回，如果本地沒有這次請求的快取頁面或者快取的頁面過期了那麼就請求後端web伺服器，後端伺服器再返回資料給反向**伺服器。靜態頁比較多時要用這個。
反向**伺服器也叫快取伺服器、網頁加速器。通常用varnish和squid，前者用得比較多。
穿透：配置反向**伺服器，不快取某些請求
varnish
squid
4.主從複製、讀寫分離
併發執行300條sql，一般乙個**70%是select語句,30%是修改的語句 （insert,update,delete)，所以一般做讀寫分離(程式）的mysql集群，這個技術是基於mysql主從復（mysql)制這個功能。
mysql主從複製：當向主伺服器插入記錄時，記錄會自動同步到從伺服器上。從伺服器是主伺服器的乙個映象，從伺服器上的資料和主伺服器總是一致的。由mysql實現。
讀寫分離：如果是寫操作，則連線主伺服器，如果是讀操作，則連線從伺服器。由程式實現。
如果mysql從伺服器也很多的話，則在web伺服器和mysql伺服器之間也需要負載均衡伺服器。
伺服器。
上傳：使用者提交到php伺服器，由php處理（縮圖等等），再由php把處理好的寫到伺服器。
6.選擇伺服器
伺服器檔次：（低檔）5000-8000元（中檔）10000-20000元（高檔）20000-40000元。
負載均衡伺服器：使用低檔的伺服器就行，因為它不需要處理請求，只需要**請求就可以，故只要有個好的網絡卡，1000m(bit)網絡卡/萬m（bit)網絡卡。
資料庫伺服器：一般使用最好的伺服器。cpu,記憶體，硬碟io要求都很高。
做磁碟陣列的型別：
raid0：至少兩硬碟，總的容量是所有硬碟容量的和，資料是分片儲存的，如存a,b兩個，那麼a存第乙個上，b存到第二個上
raid1：至少兩硬碟，總的容量是乙個硬碟的容量，資料是複製存在的，如a,b兩個，把a,b分別存多塊硬碟，所有的硬碟上的資料是一樣
raid5：至少三塊硬碟：給合了前兩種的特點、冗餘很小，而且硬碟壞了還能找回
raid1+0：效能更好的raid5,更貴
7.高可用：**是沒有單點故障的危險（任何一台伺服器壞了，不影響**整體的執行）。
為單點伺服器做乙個備份伺服器時行監聽即可，一旦主伺服器出現故障，從伺服器可以直接頂上，並給管理員發簡訊通知。 軟體： keepalived、heartbeat。
另外還需要設定防火牆，擋住一些dos攻擊。
產品和模組的設計思路
做了幾年開發了發現自己一直專注於技術，常常是我有能力但卻解決不了問題，讓我很惱火！當我們每次要涉足乙個領域的時候，我們通常要進行非常重要的一步用來打基礎，就是了解自己要做什麼？全方面的了解需求和客戶群體.當我們了解需求之後，我們要著重解決痛點，需求並不是要百分之百滿足的。我們要分析產品的特性 功能 ...
區塊鏈技術未來公鏈的設計思路
設計1.高併發的事務處理與服務介面 目前區塊鏈系統的設計已經由單鏈走向dag 分片的平行計算時代。基於dag和hashgraph的問題在於完全確認的速度較慢，且網路狀態需要不斷同步，增加了頻寬的耗費。分片技術目前仍有主鏈的概念，當資料量急速增長，一條需要眾多節點同步的主鏈必定成為效能瓶頸。參考點對點...
初始的設計思路
我們把那個底盤稱為board，該board類實乙個容器，是乙個6 6 n n 的棋盤。對於該棋盤，我們抽象的看，那是不是乙個 呢？所以我設想，這個board類從我們的table類繼承，該board類負責對底盤中的所有容器的控制。board類應該封裝乙個6 6 n n 的棋盤的事實 細節 然後應該提供...