乙個**的架構是進化出來的，不是設計出來的。
架構是為了業務服務，在業務沒有達到足夠大的量級之前，沒有必要為了架構而架構。只有隨著業務的規模變大，才逐漸有了架構的進化。
1. 單體伺服器
商品/訂單/使用者/交易 都在一台伺服器上
2. 資料庫單獨部署
應用繼續增加，應用伺服器承壓
3. 應用伺服器做集群
4. 資料庫讀書寫分離，部署多台
（1）資料庫讀寫分離怎麼操作
（2）資料庫的同步
（3）資料庫路由
5. 引入搜尋引擎
搜尋引擎的索引資料怎麼去做同步？ 實時增量同同步？ 還是定時全量同步？
6. 解決訪問量持續增高
快取 redis cdn
限流降級
7. 資料庫的水平/垂直拆分
將乙個應用伺服器按業務拆分為 商品 訂單 使用者等幾個資料庫
8. 對商品、 訂單、使用者等各個服務進行集群 （分布式）
session跨域共享問題 （cookie儲存jsessionid和 session）
session replication --> session 集中儲存 --> cookie
深度學習的模型是怎麼訓練 優化出來的
以典型的分類問題為例，來梳理模型的訓練過程。訓練的過程就是問題發現的過程，一次訓練是為下一步迭代做好指引。準備 整理資料集 將各個標籤的資料放於不同的資料夾中，並統計各個標籤的數目 如 第一列是路徑，最後一列是數目。ps 可能會存在某些標籤樣本很少 多，記下來模型效果不好就怨它。樣本均衡，樣本不會絕...
繁體字簡化出來的問題
由於多個繁體字可能簡化做乙個字，所以，從繁體字轉簡化字，比較容易！但反過來，從簡化字轉繁體字，就比較麻煩了，就算word也錯誤百出！畢竟它不知道 鬍子 的 胡 是 鬍鬚 還是 胡人 注 括號裡面的是繁體字！木板 板 老闆 板 表 表 達 鐘錶 表 離別 別，bi 別 別，bi 扭 占卜 卜，b 蘿蔔...
架構師是實踐出來的
squid nginx server s 這個覺得不可靠啊 前端使用squid做快取，後端用多台伺服器，但多台伺服器間的session不共享，為了做負載均衡，使用nginx的ip hash來做，使得 機器的會話是持續的。於是便引起來了乙個問題，使用nginx的ip hash規則來做負載均衡時，得到的...