1. 系統(tǒng)的人類用戶天生就具備進(jìn)行創(chuàng)造性破壞的本事

1.1. 用戶會(huì)消耗內(nèi)存

1.2. 用戶會(huì)做奇怪和隨機(jī)的事情

1.2.1. fuzzing工具箱、基于屬性的測(cè)試或模擬測(cè)試

1.3. 惡意用戶總是存在的

1.3.1. 災(zāi)禍總會(huì)發(fā)生，壞人肯定存在

1.4. 用戶會(huì)合伙對(duì)付你

2. 難伺候的用戶

2.1. 通常就是想掙這些挑剔用戶兜里的錢

2.2. 提高用戶轉(zhuǎn)化率或許能讓公司的損益表更好看些，但這確實(shí)給系統(tǒng)增加了實(shí)現(xiàn)難度

2.3. 最好針對(duì)這些難伺候的用戶積極地進(jìn)行測(cè)試

2.3.1. 確定系統(tǒng)開(kāi)銷最大的事務(wù)，然后將這些事務(wù)的份額增加1～3倍

2.3.2. 系統(tǒng)平時(shí)承受的平均壓力，肯定會(huì)小于上述負(fù)載測(cè)試產(chǎn)生的壓力

2.3.3. 單單構(gòu)建系統(tǒng)并處理系統(tǒng)最昂貴的事務(wù)這一件事，就會(huì)在硬件上多花費(fèi)10倍的成本

3. 不受歡迎的用戶

3.1. cookie是一種明智的選擇

3.1.1. 未加密的cookie數(shù)據(jù)可能會(huì)被惡意顧客操縱

3.1.2. 安全性要求cookie不能包含實(shí)際數(shù)據(jù)，否則就必須加密

3.1.3. cookie開(kāi)始用于小塊數(shù)據(jù)，只能用持久cookie標(biāo)記用戶，或用臨時(shí)cookie識(shí)別會(huì)話

3.2. 惡意用戶

3.2.1. 真正有“才華”的黑客

3.2.1.1. 高級(jí)持久威脅

3.2.2. 腳本小子

3.2.2.1. 數(shù)量龐大而非常危險(xiǎn)

4. 容量

4.1. 是指在給定工作負(fù)載下，系統(tǒng)既能保持提供可接受的性能，又能承受得住的最大吞吐量

4.2. 不斷增長(zhǎng)的用戶流量最終將超過(guò)系統(tǒng)的容量

4.3. 裂紋在壓力的作用下總是會(huì)蔓延得更快

5. 堆內(nèi)存

5.1. 放入會(huì)話的每個(gè)對(duì)象都位于內(nèi)存中，占用著能為其他用戶提供服務(wù)的寶貴字節(jié)

5.1.1. 最好盡可能少地保留內(nèi)存中的會(huì)話

5.1.2. 對(duì)于放入會(huì)話的每一份數(shù)據(jù)，都要考慮它是否可能永遠(yuǎn)不會(huì)再使用

5.1.3. 這些數(shù)據(jù)可能在接下來(lái)的30分鐘里白白地占用內(nèi)存，并使系統(tǒng)面臨危險(xiǎn)

5.2. 如果情況非常糟糕，日志系統(tǒng)甚至可能無(wú)法記錄錯(cuò)誤

5.3. 如果系統(tǒng)沒(méi)有創(chuàng)建日志事件的內(nèi)存，則不會(huì)記錄任何內(nèi)容

5.4. 存在這種可能，所以除了日志文件抓取之外，應(yīng)該還需要做外部監(jiān)控

5.5. 弱引用

5.5.1. 能夠在內(nèi)存富裕時(shí)保存會(huì)話內(nèi)容（也就是在內(nèi)存中），在內(nèi)存緊張時(shí)自動(dòng)節(jié)約內(nèi)存

5.5.2. 垃圾收集器需要回收內(nèi)存之前，弱引用都可以持有另一個(gè)對(duì)象，后者稱為前者的有效載荷

5.5.2.1. 當(dāng)該對(duì)象的引用只剩下軟引用時(shí)，則軟引用就可以被回收

5.5.2.2. 在創(chuàng)建弱引用對(duì)象時(shí)，可以將大型或昂貴的對(duì)象作為其有效載荷

5.5.2.3. 垃圾回收對(duì)象都是有效載荷，而不是弱引用本身

5.5.3. C#中叫System.WeakReference

5.5.4. Java中叫java.lang.ref.SoftReference

5.5.5. Python中叫weakref

5.5.6. 當(dāng)內(nèi)存不足時(shí)，垃圾收集器可以回收任何弱可達(dá)對(duì)象

5.5.7. 弱引用是應(yīng)對(duì)不斷變化的內(nèi)存環(huán)境的有用方式，但也確實(shí)增加了復(fù)雜性

6. 堆外內(nèi)存和主機(jī)外內(nèi)存

6.1. 將內(nèi)存分配給不同的進(jìn)程

6.1.1. 不要將它放在堆內(nèi)，即不要放在服務(wù)器進(jìn)程的地址空間內(nèi)，而是將其移交給其他進(jìn)程

6.2. Memcached就是使用這種方法的一個(gè)很好的工具，它本質(zhì)上是一個(gè)內(nèi)存中的鍵-值存儲(chǔ)，可以將其放在不同的機(jī)器上，也可以將其散布在多臺(tái)機(jī)器上

6.3. Redis是將內(nèi)存移出進(jìn)程的另一個(gè)流行工具。它是一種快速的“數(shù)據(jù)結(jié)構(gòu)服務(wù)器”，其定位介乎緩存和數(shù)據(jù)庫(kù)之間

6.4. 在可尋址的內(nèi)存空間和內(nèi)存訪問(wèn)延遲之間進(jìn)行權(quán)衡

6.5. 存儲(chǔ)器層次根據(jù)大小和距離排列，寄存器是最快和最接近CPU的，其次是緩存，然后是局部存儲(chǔ)器、磁盤(pán)、磁帶等

6.6. 網(wǎng)絡(luò)變得相當(dāng)快——訪問(wèn)“別人內(nèi)存”的速度快于訪問(wèn)本地磁盤(pán)的速度

6.6.1. 應(yīng)用程序最好通過(guò)遠(yuǎn)程調(diào)用獲取一個(gè)值，而不是從存儲(chǔ)中讀取值

6.6.2. 局部存儲(chǔ)器仍然比遠(yuǎn)程存儲(chǔ)器更快

6.6.3. 一對(duì)矛盾

7. 服務(wù)器上的套接字

7.1. 查看TCP數(shù)據(jù)包的格式，就能看到端口號(hào)長(zhǎng)16位，這表示端口號(hào)最大只能到65535

7.2. 互聯(lián)網(wǎng)數(shù)字分配機(jī)構(gòu)的建議范圍是49152～65535

7.2.1. 服務(wù)器最多可以打開(kāi)16383個(gè)連接

7.2.2. 可以將端口范圍擴(kuò)展為1024～65535

7.2.2.1. 最多可以有64511個(gè)連接

7.3. 虛擬IP地址

7.3.1. 操作系統(tǒng)將多個(gè)IP地址綁定到同一個(gè)網(wǎng)絡(luò)接口

7.3.2. 每個(gè)IP地址都有自己的端口號(hào)范圍

7.3.3. 要處理上百萬(wàn)個(gè)連接，總共只需要16個(gè)IP地址

7.3.3.1. 需要很多內(nèi)核緩沖區(qū)

7.4. 已經(jīng)關(guān)閉的套接字

7.4.1. 在應(yīng)用程序代碼關(guān)閉一個(gè)套接字后，TCP協(xié)議棧會(huì)多次改變其終結(jié)狀態(tài)

7.4.2. TIME_WAIT

7.4.2.1. 可以調(diào)小TIME_WAIT間隔，盡快恢復(fù)使用這些端口

7.4.3. bogon是指游蕩的數(shù)據(jù)包

7.4.3.1. 互聯(lián)網(wǎng)上的bogon是一個(gè)真實(shí)但影響較小的問(wèn)題