CDN的特點和相關信息：
使用CDN 獲取公共js http://www.bootcdn.cn/
CDN特點：CDN是和請求對應的資源是不變化的，比如靜態資源和JavaScript（URL對應的結果不變）
CDN是什么：
? ? ?1：CDN是(內容分發網絡)加速用戶獲取數據的系統，例如視頻資源
? ? ?2：部署在離用戶最近的網絡節點上 3：命中CDN不需要訪問后端服務器
? ? ?4：互聯網公司自己搭建或租用CDN
使用CDN的好處：
? ? ?01 不用去官網直接下載 02 當我們的服務上線一些穩定可靠的CDN比直接發布到我們的服務器更有效
? ? ?03 CDN也是web最重要的一個加速的功能點 怎樣讓系統抗住很高的并發的時候CDN也是一個點

高并發出現的點：
1.獲取系統時間（但是不用優化，訪問一次內存(Cacheline)大約10ns）
2.秒殺地址接口分析：
? ?1.無法使用CDN緩存
? ?2.但是它適合放在服務器緩存：Redis等->內存的服務器端的緩存可以抗很高的QPS，10^5/sQPS,
? ? ?現在Redis可以做集群，做了之后QPS可以達到10^6/s。
? ?3.為什么要做后端緩存 -> 因為后端緩存可以用我們的業務系統來控制。
? ? ?比如先訪問數據庫拿到秒殺的數據放到Redis緩存里面去，當一次訪問的時候直接去緩存里面查找，
? ? ?緩存有就直接返回，而不去訪問我們數據庫了。
? ?4.一致性維護成本比較低：當我們秒殺的東西或秒殺的對象改變了的時候，
? ? ?我們可以修改我們的數據庫，同時在改一下我們的緩存，或者干脆不改，等超時之后在改

秒殺地址接口優化：請求地址 -> Redis[一致性維護(超時穿透到SQL語句/當SQL語句更新時主動更新)] -> SQL語句

3.秒殺操作優化分析(是最重要的一個秒殺按鈕操作)：
? ?1.也是不能使用CDN緩存的，CDN不可能把你最核心的東西給緩存(大部分寫操作或最核心的數據請求一般沒辦法使用CDN)
? ?2.后端緩存困難：庫存的問題，不可能在緩存里面減庫存，否則會產生數據不一致問題。所以要通過事務來保證數據的一致性
? ?3.一行數據競爭：熱點商品，會對數據庫表中的那一行數據產生大量的update減庫存競爭

1：瓶頸分析：
update 減庫存：客戶端會執行update，根據拿到結果是否更新了，當我們的SQL通過網絡發送給數據庫時本身就有網絡延遲，
? ? ? ? ? ? ? 除了網絡延遲還有java GC（garbage collection,垃圾回收）操作 -> 不需要手動去回收，
? ? ? ? ? ? ? GC自動就幫我們回收了，新生代GC會暫停所有的事務代碼（Java代碼）后，執行GC（一般在幾十ms），
? ? ? ? ? ? ? 并且，同一行事務是做串行化的。

----》insert 購買明細：也會存在網絡延遲和GC
----》commit/rollback
也就是說如果是Java客戶端去控制這些事務會有什么問題：update 減庫存（網絡延遲，可能的GC，GC不一定每次都出現，但一定會出現）
--> 執行insert 購買明細（在網絡延遲等待insert語句的返回，然后也可能會GC） --> 最后commit/rollback。
當前面的這些操作都執行完之后，第二個等待行鎖的線程菜能夠有機會拿到這一行的鎖在去執行update減庫存

特點：
? ?根據上面的拆分，所以QPS很好分析了 --->（我們所有的SQL執行時間 + 網絡延遲時間 + 可能的GC）
? ?這一行數據就是當前可以執行的時間.比如時間是2ms,概念是1s之內只能有500次減庫存的秒殺操作，但是對于
? ?秒殺系統，特別是熱點系統來說其實是不能滿足我們的要求的，特別是排隊特別長的時候，性能會呈現指數級別下降
得到的點是：行級鎖是在commit/rollback之后釋放的；
優化方向：怎樣減少行級鎖持有的時間 ---> （當你update表中一行數據的時候，一定要快速的commit/rollback，
? ? ? ? ?因為其他還在等待，因為這是一個熱點的數據）；

2：延遲分析：
延遲問題是很關鍵的；
優化思路：
-把客戶端邏輯放到MySQL（數據庫）服務端，避免網絡延遲和GC影響
-如何放到MySQL服務端：

--兩種解決方案：
---定制SQL方案： 早期的阿里巴巴的天貓做了一個MySQL的源碼層的修改 --->update/*+[auto_commit]*/，
? ?但是執行完這句update之后，會自動進行回滾（條件是：當update影響的記錄數是1，它就會commit，如果等于0就會rollback）
? ?也就是說它不給Java客戶端和MySQL之間網絡延遲，然后在由Java客戶端去控制commit還是rollback，而是直接用這條語句直接發過去
? ?告訴它是commit還是rollback。本質上也是降低了網絡延遲和GC的干擾，但是成本很高 --> 需要修改MySQL源碼，大公司可以這樣的團隊

--使用存儲過程： 整個事務在MySQL端完成；存儲過程設計出來的本質就是想讓我們的一組SQL組成一個事務，然后在服務器端完成，
? 而避免客戶端去完成事務造成的一個性能的干擾。一般情況下像是spring聲明式事務或我們手動控制事務都是客戶端控制事務，
? 這個事務在行級鎖沒有那么高的競爭情況下是完全OK的，但秒殺是一個特殊的應用場景，它會在同一行中產生熱點，大家都競爭同一行父，
? 那么這個時候存儲過程就發揮作用了，它把整個這條SQL執行過程完全放在MySQL中完成了，
? MySQL執行的效率非常高，因為我們都是通過主鍵去執行的，查詢或更新

優化總結：
1：前端控制：暴露接口，按鈕防重復
2：動靜態數據分離：CDN緩存，后端緩存
3：事務競爭優化：減少事務鎖時間 ---> 這是秒殺用MySQL解決秒殺問題的很重要的一個關鍵點；
? ?因為用事務有一個很大的優點是：保證原子性、隔離性、一致性、持久性。

你說的數據庫同步問題，現在在做分布式數據庫的時候是有中間件來對數據進行同步的，如果是主從備份的話，只需要在主庫中做好事務，在主數據庫中提交事務后，從數據庫的數據會自動同步的，不存在你所說的數據同步的問題。