一，產品經理所要做的事：
1.市場定位
2.產品差異
3.功能特性
4.競爭狀況
5.市場研究
二：生產者和消費者
為什麼要有郵箱，如果寄信人直接把信交給郵遞員會出現什麼後果？這就造成寄信人和郵遞員有直接的依賴。
在計算機程式設計中，很多生產者和消費者的模式，消費品就是資料。用什麼來儲存這些資料和操作這些資料呢：
1.用執行緒來操作佇列
2.用程序來操作管道
3.使用socket
雙緩衝：
雙緩衝就是有兩個緩衝區a和b，開始的時候，生產者向a寫入資料，消費者從b讀取資料，生產者把a的資料填滿後釋放鎖並等待消費者釋放b的鎖，消費者從b讀取所有的資料後，消費者得到b的鎖並向b寫入資料，消費者也得到a的鎖並從a讀取資料.a和b由生產者和消費者交接使用。如果生產者和消費者同時處理完各自的緩衝區，同時去獲取對方的鎖，那就會出現死鎖，生產者和消費者陷入萬刧不復的境地.
三：大型web2.0**架構面臨的問題：
a.海量資料處理:小站點的資料量並不大，select和update的成本也不大，針對查詢最多建立個索引也就差不多了.但對於大型**，使用者在千萬級別以上的，對乙個表的select和update(還不說多表聯合查詢)的成本是非常高的，我們需要乙個有效的資料處理方案.
b.資料併發處理:解決這個問題常用的策略就是快取，然而在高併發的情況下有兩個或者更多請求同時對快取有更新要求時，雖然我們有lock機制，但有時還是遇到些問題，所以需要乙個好的資料併發處理策略和快取策略.
c.檔案儲存問題:我們考慮如何儲存檔案和有效的索引檔案，如果乙個500g的磁碟儲存著零散的檔案，磁碟的io是乙個巨大的問題，哪怕你的頻寬足夠，但是你的磁碟未必能響應過來，如果還讓使用者讓傳，那麼磁碟很容易就over。也許用raid和專用的儲存伺服器能解決這個問題，但這樣的話存在異地訪問的問題，如果伺服器在雲南或海外，訪問速度如何解決？如果做分布式，那麼檔案索引和架構如何規劃?檔案儲存這個問題沒那麼容易對付.
d.資料關係處理:我們很容易規劃出乙個符合第三正規化的資料庫，裡面布滿了多對多的關係，但在多對多關係充斥的2.0時代，第三正規化首先應該被拋棄，因為我們必須有效地把多表聯合查詢的機率降到最低。
e.資料索引問題:眾所周知，要想提高資料庫查詢效率，索引是最方便，最廉價的方案，但是在高update的情況下，update和delete的成本會高的無法想像，如果更新乙個索引需要5分鐘去完成，這對於web2.0來說是乙個不可忍受的，所以索引和更新是一對冤家。
f.分布式處理：如何實現資料同步和更新，實現各地伺服器的實時通訊並保證各地的訪問速度是分布式所要面對的問題.
g.ajax利弊分析：成了ajax，敗也ajax，但今天它在了主流。ajax可以將使用者的體驗做得很好，經過一些設定還可以使一些基於webbrower的類似的元件的http攻擊無效，但如果基於http資料報處理方面，ajax很容易受到攻擊。由於基於js，我們可以很容易理解它的加密驗證方法，對於一些計算量大的ajax請求，我們可以構造發包機，很容易就把乙個伺服器乾掉.
h.資料安全性分析：http協議的資料報都是是明文傳輸的，也許你說我們可以加密啊，沒用的，如我們知道的qq，可以很容易知道它的加密方法並可以寫出乙個一樣的加密和解密方法出來，當站點流量不是很大的時候沒有人在乎，但是流量上來後所謂的外掛程式，所謂的**就接踵而來了.也許你說可以用更高階別的判斷和https來實現，但當你做這些處理的時候，付出的是海量的database,io以及cpu的成本。
i.資料同步和集群處理:當資料庫伺服器不堪重負時，我們就需要做基於資料庫的負載和集群了，這時的問題是基於網路傳輸時會發生資料延遲，這是很可怕但也是不可避免的問題，我們需要通過另外的手段保證在這延遲的幾秒或更長的時間內實現有效的互動，比如資料雜湊，分割，非同步處理等.
j.open api以及資料共享:open api已經成了不可避免的趨勢，從google，facebook到海內，校內都在考慮這個問題，它可以有效地留住使用者，讓更多人幫助你做最有效的開發，如何在開放介面的同時保證資料的安全和效能是需要認真思考的問題.
k.大量like,or,in以及多表查詢帶來的效能屏障：or,in,多表查詢會造成全表遍歷，如果涉及多個or查詢的話會成為另外乙個瓶頸，特別是在多對多關係漫天的sns站點來說更是需要乙個有效的處理方案.
l.大量上傳檔案攻擊：我們可以對上傳作一些限制，如許可權和上傳的頻率，但是當資料量很大的時候，我們需要更多考慮：如何建立一套更高效的效能更好的判斷處理方案.
架構策略：
我們暫時先把使用者量級別定為三種：百萬級別(m)，千萬級別(s)和億萬級別(q)，如何最大化地保證查詢和更新，在此涉及優化和索引，只講架構初期的方案：
1.對於m級別的使用者來說，現有的dbms經過合理的布局完全可以滿足需要。問題的關鍵其實是應對io問題，處理的方案相對簡單，對資料庫檔案分盤儲存(不是分割槽，是不同的硬碟)。
2.對於s級別，我們需要對註冊和入庫的流程進行簡單修改，解決方案是資料雜湊和分割槽檢視，常用的方案有三種：
a.第一種是等容擴充法：在使用者註冊控制的基礎上，保證每個庫的使用者容量不超過500萬，超過後就入第二個庫，以此類推，這個方案可以保證系統的有效擴充性，但不能保證資料有效地被索引.
b.第二種就是共區索引，和第一種有異曲同工之處,但是對第一種方案進行了合理的優化，按照使用者名稱進行了分庫儲存，比如我們建立10個資料庫，如果使用者名稱是crazy，那麼儲存在c表中，所以很容易根據使用者名稱進行相應的資料查詢，所以方案二有效地解決了資料索引問題.
c.方案三是一和二的結合，進行使用者id的編碼，用序列化的一種方案將使用者名稱以編碼的形式儲存，如使用者名稱crazy按照c,r,a...儲存為資料索引，然後進行分割槽儲存，數字型別的資料可以在資料庫中更有效地被查詢，更新和共享.
3.對於q級別，資料量已經夠海量了，無論用哪種方案都是頭痛的問題.我們可以用乙個臨時的資料庫，把最活躍的使用者放到這個庫中，查詢的時候先查詢臨時庫，如果沒有再進行全庫查詢.
以上對m,s,q三種級別進行了概述，下面介紹乙個更高階的查詢方案：資料快取伺服器，我們可以把它理解為緩衝伺服器，資料作為唯讀使用.可以把最常用最直接的資料放到快取伺服器中，而這個快取伺服器定時從主伺服器中獲取並更新資訊，更深入的還可以將快取伺服器再進行地次快取.下面一點點介紹具體的解決方案：
(1)多對多優化處理
對於多對多關係，傳統的處理方案有三種，第一種是通過search的方法來實現，第二種是通過建立乙個索引表，儲存對應的id,第三種是通過二次歸檔緩衝來實現。對於第一種方案要用大量的like查詢，效能不敢恭維，基於全文索引可能解決這個問題，但利用第三方的資料未必適合我們的胃口.第二種情況下，要維護索引表，並且要跨表查詢，還要維護資料的唯一性，如果表裡的資料大的話效能是相當低的.下面用標籤和文章的例子來講第三種方案：
在傳統的資料設計中，當一篇博文發表的時候，一般是三步走：第一步插入文章資料庫並獲取文章id;第二步插入標籤資料庫同時查詢標籤是否存在，如果存在就取出標籤的id,如果不存在就插入新標籤並取出標籤id;第三步將文章id和標籤id插入索引表建立關聯，如果這個時候在索引表上建立了索引，那就是災難性的，特別是資料量大的情況下，儘管它可以有效提高查詢速度，但發布的速度可能會讓人無法忍受...那麼如何進行優化呢，請看優化四步曲：
第一步.資料冗餘：使用標籤時，用得最多的，就是查詢標籤下的文章和顯示文章的標籤，這樣的話，為了避免跨表查詢和inner join查詢，可以對文章表做冗餘，加上乙個標籤列，同樣對於標籤表，也可以作冗餘，加上乙個article列。
第二步.非同步存貯：平常程式設計中，我們會用到設計模式中的單例模式。。。在發表文章的時候，經常會因為要檢查標籤表造成執行緒擁堵，為了避免這種情況可以採用延遲載入方案。伺服器應該維護乙個程序，專門對標籤和文章進行查詢和索引。在發布文章時，我們還可以把標籤同步這一工作託管給另外的程序或者伺服器進行處理，並進行索引.
第三步.二次索引：對於一些需要頻繁判斷的熱鬧標籤，我們還可以在內在裡組織一套有效的索引，怎麼樣組織這樣乙個記憶體索引，可以用樹來表示..
第四步.針對跨表查詢的處理：處理的方法也很簡單，把原來雜湊的，垂直分割的表現合併起來放到另外的吟詩伺服器上，然後再作適當的結構優化和索引，剩下的就簡單了.
(2)讓併發來的更猛烈些吧
在資料高速增長和併發呈幾何增長的情況下，制約我們的可能會是io和database方面的問題，頭痛的是不管用哪種資料庫都會出現超時，而且是頻繁超時，頻繁出現異常。乙個好的快取策略常常決定我們的成敗，在大型**架構中，最關鍵最核心的也就是快取策略了。
傳統的資料操作流程是這樣的：使用者在瀏覽器中傳送乙個web請求到web伺服器，web伺服器通過資料驅動直接到資料庫進行操作。現在講下基於高併發的資料庫快取方案，後面介紹常用的快取策略，這個快取方案實現的原理很簡單，我們需要四類伺服器：web伺服器(組)a，資料緩衝**伺服器b,cache伺服器c,資料庫伺服器d:（參考檔案）
架構就是關注點分離
要設計良好的架構，必須做到關注點分離，這樣可以產生高內聚，低耦合的系統，這就是美麗架構的終極原則。
架構就是系統的組成部件及其之間的關係。根據視角不同，架構可以分為業務架構和技術架構，一般來說，功能性需求會對業務架構產生影響，而非功能性需求會對技術架構產生影響.
例如：註冊使用者可以向自己的相簿上傳，並與好友分享。這是乙個功能性需求，它告訴了我們在系統的業務架構中，會出現註冊使用者，相簿，，好友等組成部件，它們之間存在相互關係。而系統可以支援10萬併發使用者，並在需要時可以方便地伸縮，擴充套件到支援100萬到1000萬的併發使用者，這則是一項非功能性的需求，它告訴我們系統在效能，負載，吞吐量，可伸縮方面的特性。架構體現的是對複雜系統的分解設計，如何進行分解，則是軟體設計的永恆話題。
《程式設計師》雜誌 2017 精華本
內容簡介 生物在適者生存的 演化 過程中塑造，而未必愈加清晰地感知世界。例如青蛙的大腦被設定為捕食移動的橢圓。把蒼蠅麻醉，擺在它旁邊，青蛙視若不見 他們能餓死在食物近前 然而又會毫不猶豫地捕食由人丟擲的小紙片，直到再也無法下嚥。青蛙只能看到你我所見的一小部分，卻以為自己了解整個世界，那我們呢？計算機...
普通程式設計師的2009
過了0 點了,現在是我 出爐 31年零一天了。好幾次都想寫關於 2009 的總結，但是寫了一些又放棄了。這一年經歷太多，收穫很多，也學會很多，也總算是成熟了。今天給top 團隊的同學做了年前最後一次分享，主要是把 top服務控制的內容全部重新梳理後，重新全域性的介紹了一下。雖然還是大家自願來的方式，...
普通程式設計師的2009
過了0點了,現在是我 出爐 31 年零一天了。好幾次都想寫關於2009 的總結，但是寫了一些又放棄了。這一年經歷太多，收穫很多，也學會很多，也總算是成熟了。今天給top 團隊的同學做了年前最後一次分享，主要是把top 服務控制的內容全部重新梳理後，重新全域性的介紹了一下。雖然還是大家自願來的方式，但...