寫在前面：感謝GeekBand提供這樣好的學習機會，讓我在繁忙的工作之余可以學習鞏固c++知識。以下是邊學邊記的一些擴展點。分享給大家。
Concurrency
進程與線程 (Thread VS Process)（http://www.lxweimin.com/p/177e9b073ce8）
程序在操作系統運行的基本單位，提高應用的并發性。程序擁有至少一個進程，一個進程至少有一個線程。多線程程序，并發性比較高；進程執行時候有獨立的內存單位，而線程可以共享內存以提高效率。每個獨立的線程有個程序運行的入口，數據執行的序列和程序的出口；操作系統中對進程的調度分配來達到資源管理的目的，進程是系統進行資源分配的獨立單位。
**生產者與消費（Consumer and Producer ） **
操作系統的有限和緩存的問題，多線程同步問題的案例。生產者線程生產數據放入緩沖區，同時消費者從緩沖區中消耗數據。問題的關鍵在于如何使得：生產者不在緩沖區滿的時候加入數據，消費者不在緩沖區空的時候消耗數據。
生產者與消費的經典應用： Blocking Queue （Java實現）
生產者與消費的經典應用
Tracking:
同步（Synchronized ）
異步（Asynchronized ）：建立緩沖區
Network
Application Layer : HTML 1.0 VS HTML 1.1： 后者支持虛擬主機和斷點續傳
Presentation Layer： TCP VS UDP：前者連接可靠，后者效率高
問題：當瀏覽器輸入URL并且按下回車鍵之后會發生什么？
找IP地址：先URL 緩存 ，然后DNS
得到返回IP地址
本地計算機和服務器通過IP建立TCP連接（三次握手），默認80端口
瀏覽器和服務器建立HTTP會話（Session），接受數據
瀏覽器解析數據并在瀏覽器中渲染出來
瀏覽器關閉時，終止會話。
Database
Relational DV VS KeyValue Store
前者典型例子：銀行存錢系統，需要實時；
后者典型例子：社交網站，簡單，量大
Sharding VS Clustering直接拆分與負載智能管理
關于Tiny URL 問題：為URL存儲短URLCode映射成URL（Tiny URL Service ），需要保存成下面的格式：
code：varchar（8）
URL：varchar(1000)
createed_at: timestamp
還需要能夠反向將URL映射成code
需要給URL和Code加索引，一遍可以反向將URL映射成Code
Distribute System
關于Tiny URL 問題： 如何規模化Tiny URL Service
負載均衡和無狀態的前置服務器
分片，備份的數據庫（備份大量的short link code）
交互需要加緩存，減輕服務器壓力
根據分好的片定位到數據庫相應的區間，緩解寫的壓力
本地緩存事件追蹤聚合+異步刷新到高吞吐（high-throughput）的信息隊列中
使用產生的唯一ID生成器，支持64位
Performance
問題： 全世界有多少鋼琴調音師（邏輯推理，估算能力）
流程：全世界人口總數和家庭個數；
估計大概10~20%家庭會有鋼琴，得出鋼琴個數；
每個鋼琴調音師大約每個月工作4-5次；
最后得出有多少鋼琴調音師可以滿足這些需求。
關于Tiny URL問題： 我們也可以估算總體存儲量是多少。
因為URL長度是10-1000字符(byte)，取平均值是200 byte;
計算總共需要URL的數量：
假設我們已經擁有100M個URL，新的URL注冊的數量是100,000/天（每秒一個）
那么一年的URL的條數就是100,000 x 365 條,即36,500,000 byte,
如果一天查詢100M次，那么每秒查詢就是1000次。
發現：讀的數量遠大于寫的數量，可能需要做緩存，讀寫分離。
Design Pattern
MVC：連接模型到某個前端；
Singleton：保證只有一個實例，比全局變量靠譜。可以隨時直接更改；
Factory：定義創建對象的接口，讓接口決定實例化哪個類。用于生成各種子類的時候；
Iterator：順序訪問集合中的元素，同時不會暴露集合中的元素。需要保證插入和刪除不會影響到其他對象；
Decorator：用一個新的類，對對象新增附加方法，指向基類的指針，調用時用多態調用就可以了；
Facade：提供一致的界面，提供一致的接口。
