做系統時，開始階段設計領域類時，除了從資料結構、物件模擬的角度出發，特別是訪問量大的時，還應該考慮資料的實際應用場景，區分資料的常變部分(或稱瞬時狀態)和不常變部分。將常變部分和不常變部分剝離，能更好為其制定適當、高效的訪問策略。
我以陶寶商品為例子。陶寶商品的不常變部分是：商品的基本資訊、狀態；常變部分是：商品瀏覽次數。
一般的設計：
使用者每次瀏覽某個商品時，伺服器總是準備好上面的所有資料，一次向瀏覽器flush顯示出來。
可是，陶寶不是這樣做：陶寶的乙個商品頁面並不是一次由伺服器準備好，統一向瀏覽器flush完成的。
它把頁面分為若干塊，不同塊的資料從不同的伺服器請求：
有伺服器(這沒什麼特別的，不是本貼的主要說明點)
樣式有樣式伺服器(這沒什麼特別的，不是本貼的主要說明點)
基本資訊有基本資訊伺服器(web伺服器)
商品瀏覽次數有「次數伺服器」(可能是另外的web伺服器)
。。。這裡作為常變資料的商品瀏覽資料並不是隨商品資料合為一塊傳送到瀏覽器的。
ok。這樣做到：各部分可以很好利用各部分的特性，做擴充套件、做快取、做即時性的不同承諾。
像商品瀏覽次數這種每次只要使用者瀏覽就需要變更的，只需要update常變資料伺服器，而不用立即持久化。
這樣，那些不常變資料的快取的作用和效果將極其明顯。
頁面在達到使用者瀏覽器時，再通過ajax技術，從常變資料伺服器獲取那些常變資料。
(這個時間段，該資料將顯示空白，不過這一點也不影響使用者體驗):
在設計表時，不必一定要把「瀏覽次數」列設計在基本資訊表裡。「瀏覽次數」之類的資料可以是單獨的伺服器，以商品id作為其身份證非同步地從瀏覽器發起向那個單獨伺服器去取。
--------------------
只要把快取作為一項高階決策來做，不要因為快取中介軟體提供簡單的api，就想用就用，不想用就不用，一般就不會太失望。
考慮乙個關於需求特性的問題
特性，在產品研發裡，應該算是包含在需求之中。沒有明確的需求，就沒有明確的產品。可是產品的需求，不可能是開始就是需求完善的，開始的時候，絕大多數的需求都是潛在的 隱含的 暗示的。在產品研發過程中，每個設計，每個問題的答案，每個問題的討論和解決，其實都是和產品的需求緊密聯絡的。一旦我們思考，這是否是個問...
乙個需求技術選型的考慮過程
前段時間，專案中遇到乙個需求，是在a系統進行一些操作後，往資料庫存資料時，觸發b系統，b系統把資料也同時存放到資料庫中，要求是兩邊的資料要相同，在a系統又不能直接操作b系統中的表 出於耦合性的考慮 技術選型的考慮過程是 1.用service httpclient的方法，結果邏輯太多，計算複雜，很可能...
設計乙個海量的影像庫發布系統應該考慮的問題
最近，我們開發了乙個遙感影像發布系統，在此將當時調研 技術選型 設計等方面的想法總結一下。一 保證足夠的響應速度 採用多個web伺服器，增大吞吐量 合理配置web伺服器，使其發揮最大效能 為資料庫伺服器分配較大的快取，如2g ram可取1.8g作快取 提高硬體配置，如使用多cpu的伺服器 增大記憶體...