注冊
一般來說，注冊模塊並沒有什么難點，但我在注冊模塊中寫了兩種驗證碼（普通驗證碼，短信驗證碼），普通驗證碼沒有難度，但手機驗證碼需要在twilio網獲取免費手機號，通過這個手機號給注冊用戶發短信驗證碼。
作用：
注冊驗證邏輯 短信+郵件+驗證碼 防止機器人重復注冊
登錄
我的登陸模塊寫了第三方登錄，因為大多數網站都有第三方登陸，並且第三方登錄可以省許多時間，比較方便。
關於三方登錄的授權機制
在授權過程中大致有三個對象。一個是服務提供方（第三方網站）、一個是用戶（將資源放在服務提供方存放的對象）、還有一個就是客戶端（向服務提供放請求用戶資源的對象）。首先，客戶端向服務提供方發起請求，請求服務提供方的一個臨時令牌，這個臨時令牌是進行下一步的基礎，服務提供方先要驗證一下客戶端的身份，驗證成功后會給客戶端所要的臨時令牌。接下來客戶端會引導用戶進行授權操作，用戶進入服務提供方提供的頁面，完成授權以后服務提供方會給客戶端一個訪問令牌並調轉回客戶端的網頁。通過訪問令牌，客戶端就可以獲得用戶在服務提供方上的若干權限
綁定邏輯：
判斷user_social表中是否存在該openid的數據。
若存在，直接進行登錄。
若不存在，將數據，存儲到user_social 表，引導用戶綁定本站賬號。
若本站已存在賬號，直接關聯賬號即可。
若本站不存在賬號，引導用戶注冊，成功后與當前openid關聯即可。
商品詳情頁
功能：
1.加入購物車
2，收藏
3。評論
加入購物車
需求分析：
購物車首先標識要唯一，因為每個賬號要對應一個購物車，在登錄狀態下，我們可以直接將數據保存到數據庫中，使用用戶的id表示自己購買的商品，但是如果在未登錄狀態下呢，或者對購車訪問量大的時候，這個就存在弊端，因為這樣高速的讀寫數據庫，會對數據庫的壓力比較大。
所以，我采用存入cookie和redis這兩種數據庫中。
方案一 ：客戶端 cookie 弊端：客戶端不可控，可能禁用cookie。
方案二 ： 服務端 redis 推薦使用。
redis:
利用redis key的唯一性來實現。並且采用分表的形式。
為什么分表？
隨着公司業務增長，如果每天1000多萬筆訂單的話，3個月將有約10億的訂單量，之前數據庫采用單表的形式已經不滿足於業務需求，數據庫改造迫在眉睫。
解決思路：
按月分表，將原訂單表拆分為 order_201901 order_201902 由此類推
這樣就可以緩解數據庫壓力 根據業務場景 可以細分按周，按日分表
購物車存到cookie
為什么不存session？
首先，session存在時間限制，會定期清空的，而cookie如果不主動清或者設置定期則不會清楚；
session存放在服務器端，cookie存放在客戶端瀏覽器。
購物車存放的都是臨時的物品，購買之后才產生真正的交易記錄，所以這部分數據一般不會放到session中。session還有一個問題就是容易失效，默認20分鍾左右會自動銷毀。所以存放到cookie中是比較合理的選擇。
Cookie方式：
優點：購物車信息存儲在客戶端，不占用服務器資源，基本可以到達持久化存儲。
缺點：Cookie有大小的限制，不能超過4K，而且不夠安全。如果是個人PC機，Cookie能很好的保存購物車信息，但如果是公共辦公環境，Cookie保存的信息基本就失效了(會被其他人購物車信息覆蓋)。對一個大型的電子商務網站，我們需要對用戶的購買行為進行分析，需要對用戶推薦用戶感興趣的商品，如果把購物車信息保存在Cookie中，則不能對用戶購買行為分析統計。
為什么要用兩種購物車？
防止其中一個購物車發生異常，兩種購物車可以進行無縫切換。
收藏
為什么寫收藏功能？
1，我對這一件商品感興趣，但我不買。
2.我沒錢，等着打折。
3，我喜歡這個風格的衣服，我還不確定我買那一件。
4.收藏功能由於沒有任何的限制及使用成本。我們經常會把看到的喜歡的、想特意關注的、等以后有錢再買的等各種產品放置收藏夾，等待下一次時機成熟時進行購買。
所以，收藏功能誕生了。
評論：
評價這個功能是非常重要的一個功能，他有利於顧客更好的了解這個商品的優缺點，並且可以讓商家及時看到這個商品需要在那個地方進行改正。
評論存在的目的：
1.將用戶在購買后對商品、服務、物流等相關信息的真實感官表現出來，為其他用戶提供購買決策，減少購物成本。
2.對於平台來說提高復購率；構建商家信用評價體系，幫助商家分層，合理分配平台資源。
3.對於想買的顧客來說，有購買意願的買家需要了解商品的真是情況，獲得高質量的評價幫助自己購物決策，是評價產品的高頻使用者，此類買家由於厭倦海量的評價、對真實評價有迫切的需求，往往會更加注重評價的篩選，有圖評價和追加評價更容易被關注。
4.對於以及購買的客戶來說，已經購買的買家可以分為兩類，一類是對商品、服務、物流有超預期的體驗或者發表不滿的情緒，這類買家的評價重要性權值要高很多，要讓這類買家在產品使用過程中盡可能多的機會來發表建議（包括評價問答）；另一類就是商品和預期差不多的買家，這部分買家占據大多數，通常不會將自己的感受表現出來，這時需要平台介入提高評價率，簡化評價流程，降低成本。
5.評價對賣家來說一種特別好的收集用戶反饋流程，通過評價可以幫助優化購物體驗、商品品質。但賣家反而是評價系統的風險用戶，由於評價會直接影響客流轉化，所以賣家會更有意願去破壞評價初衷和規則。
邏輯：
（1）單篇文章的評論數量和信息展示；
（2）從時間維度，按照時間倒敘的方式展示動態的用戶評論信息；
（3）不同欄目，不同模塊，不同時間維度的評論排行展示；
（4）精華評論的單獨推薦和聚合展示；
（5）評論后直接分享到綁定的第三方平台；
（6）點贊數、回復數等維度的排行等。
在評價的時候，其他顧客也可以進行提問或者發表其他意見。
數據表設計：
一問一答模式
(1)需求分析
大部分APP采用簡單的評論設計即可，即是一問一答模式，比如微信朋友圈的評論功能的設計。如：
A：今天天氣真好！
B @ A :今天天氣確實不錯！
1
2
這種設計簡單、直接，也滿足了用戶評論、回復的基本要求，對於沒有大量用戶評論的APP需求足夠。
（2）數據庫設計
這種場景下一般評論較少，評論不活躍，可以不區分評論和回復，統一看成評論。區別是，有些評論是直接評論主題，而有些是@其他用戶，使用一張表就可以達到效果，評論表設計如下：
表字段 字段說明
id 主鍵
topic_id 主題id
topic_type 主題類型
content 評論內容
from_uid 評論用戶id
to_uid 評論目標用戶id
topic_type：為了能復用評論模塊，我們引入這個字段來區分主題的類別。
from_uid：表示評論人的id，通過該id我們可以檢索到評論人的相關信息。
to_uid 是評論目標人的id，如果沒有目標人，則該字段為空
出於性能的考慮，往往我們會冗余評人的相關信息到評論表中，比如評論人的nick、頭像，目標用戶也是如此。 這樣一來我們就只用查詢單表就可以達到顯示的效果
有時，目標用戶有多個，那么可以將to_uid字段修改為to_uids，保存時用分隔符來分割用戶id，而目標用戶的信息再去查詢緩存或者數據庫。也可以簡單的將多個目標用戶的信息一起存成json格式，可以應付簡單的展現需求。
2.2 評論為主模式
(1)需求分析
論分為評論和回復，所有評論均掛在評論下面，類似於樹狀結構。
（2）數據庫設計
在以評論為主的樹形顯示情況下，數據庫的設計十分靈活，可以使用單表，添加一個parent_id字段來指向父評論，需要嵌套查詢。
同時也可以將評論拆分為評論表和回復表，評論掛在各種主題下面，而回復掛在評論下面。
評論表設計如下：
表字段 字段說明
id 主鍵
topic_id 主題id
topic_type 主題類型
content 評論內容
from_uid 評論用戶id
回復表設計：
表字段 字段說明
id 主鍵
comment_id 評論id
reply_id 回復目標id
reply_type 回復類型
content 回復內容
from_uid 回復用戶id
to_uid 目標用戶id
由於我們拆分了評論和回復，那么評論表就不再需要目標用戶字段了，因為評論均是用戶對主題的評論，評論表的設計更佳簡潔了。
回復表添加了一個comment_id字段來表示該回復掛在的根評論id，這樣設計也是出於性能方面的考慮，我們可以直接通過評論id一次性的找出該評論下的所有回復，然后通過程序來編排回復的顯示結構。 通過適當的冗余來提高性能也是常用的優化手段之一。
reply_type：表示回復的類型，因為回復可以是針對評論的回復(comment)，也可以是針對回復的回復(reply)， 通過這個字段來區分兩種情景。
reply_id：表示回復目標的id，如果reply_type是comment的話，那么reply_id＝commit_id，如果reply_type是reply的話，這表示這條回復的父回復。
2.3 網易新聞蓋樓模式
（1）需求分析
這種場景中評論和回復是同級顯示的，回復不在顯示結構上不用掛在一個評論下面。 雙表的設計在這里就不太合適了，因為涉及到評論和回復的混排，使用雙表則會導致查詢的邏輯過於復雜。 所以建議還是采用單表的設計，不區分評論和回復會簡化應用層的邏輯。 我們統一都看成評論，而有些評論是可以引用其他評論的。
秒殺功能
雙十一剛過不久，大家都知道在天貓、京東、蘇寧等等電商網站上有很多秒殺活動，例如在某一個時刻搶購一個原價1999現在秒殺價只要999的手機時，會迎來一個用戶請求的高峰期，可能會有幾十萬幾百萬的並發量，來搶這個手機，在高並發的情形下會對數據庫服務器或者是文件服務器應用服務器造成巨大的壓力，嚴重時說不定就宕機了，另一個問題是，秒殺的東西都是有量的，例如一款手機只有10台的量秒殺，那么，在高並發的情況下，成千上萬條數據更新數據庫（例如10台的量被人搶一台就會在數據集某些記錄下 減1），那次這個時候的先后順序是很亂的，很容易出現10台的量，搶到的人就不止10個這種嚴重的問題。那么，以后所說的問題我們該如何去解決呢？ 接下來我所分享的技術就可以拿來處理以上的問題： 分布式鎖
在購物平台中，秒殺通過對一些商品經過折扣優惠來吸引一些客戶流量。
秒殺功能的邏輯：
1 請求量大，請求高並發； 2 用戶瞬間活躍量高，要求系統響應快；
3 秒殺商品少，只有少數用戶能夠買到。
4.秒殺頻道首頁列出秒殺商品（進行中的）點擊秒殺商品圖片跳轉到秒殺商品詳細頁。
5.商品詳細頁顯示秒殺商品信息，點擊立即搶購實現秒殺下單，下單時扣減庫存。當庫存為 0 或不在活動期范圍內時無法秒殺。
6.秒殺下單成功，直接跳轉到支付頁面（支付寶），支付成功，跳轉到成功頁，填寫收貨地址、電話、收件人等信息，完成訂單。
7.當用戶秒殺下單 5 分鍾內未支付，取消預訂單，調用支付寶支付的關閉訂單接口，恢復庫存。
利用redis的setnx鎖來實現不能超賣
利用 apache bench 進行壓力測試
服務器負載太大而影響程序效率也是很常見的，Apache服務器自帶有一個叫AB(ApacheBench)的工具，可以對服務器進行負載測試
同時美多商城的秒殺功能也會被高負載影響，從而導致超賣現象
基本用法:
ab -n 全部請求數 -c 並發數測試url
注：可以將ab.exe 加入系統環境變量；或直接切換置 ab 目錄執行。如： C:\Windows\System32> cd C:\xampp\apache\bin
引申出redis緩存和mysql數據庫數據同步問題
解決方案 redis設置超時時間，一旦超時，數據就會同步
我的訂單：
我實在購物車中點擊結算后添加到我的訂單中，並進行購買。
我為什么要加入訂單而不是立即購買，因為我在購物車中點擊結算后添加到我的訂單時，會生成訂單號，通過這個生成的訂單號進行購買。
第三方支付：
我使用的是支付包支付。
神魔是第三方支付：
第三方支付是指具有一定實力和信譽保障的第三方獨立機構。通過與各大銀行簽訂合同，建立連接用戶和銀行支付結算系統的平台，從而實現電子支付模式。從另一個角度來看，第三方支付就是非金融機構提供的網絡支付、預售卡發行與受理、銀行卡收單等零售支付服務。
作為一種創新的支付方式，第三方支付極大地方便了人們的生活。但與此同時，第三方支付機構由於自身的運營機制，容易出現支付欺詐、信息泄露、信用違約等問題，這引起了公眾和相關監管機構的關注。
第三方支付的優勢：
第三方支付作為當代支付方式發展的核心驅動力，具有以下優點。
一是扮演信用中介的角色。第三方支付大大改善了商品交易中買賣雙方信息不對稱造成的猶豫銷售或購買的問題，促進了商品經濟的數量和質量，同時保證了雙方的財產安全。
二是擴展支付。它允許消費者隨時隨地購物、生活繳費，如支付水費、電話費甚至會員費，結束了過往使用手機卡、游戲卡和其他充值卡的時代。
三是加快建立全民信用信息系統。同時，信用評分已成功應用於消費者的日常生活。以太原市圖書館為例。只要讀者的芝麻信用達到600分或以上，您就可以申請圖書館借閱卡而無需押金，可以借4本書。此外，支付寶依靠天貓商城推出“信用嘗鮮”服務，這意味着信用合格的客戶可以先享受試用天貓服飾，先享后付天貓電子產品等權益，為信用信息系統的發展注入強大的力量。
第三方支付通俗來講就是微信支付，支付寶支付，財付通等；
第三方支付的邏輯：
1.使用沙箱提供的商家環境
2.生成密鑰對
3.將公鑰加到商品環境中
4.將Alipay提供的公鑰加入項目中
5.支付功能
6.根據order_id查詢訂單對象
7.創建alipay對象
8.調用方法,生成url
9.返回url
10.保存支付狀態
11.根據返回的url請求支付寶
12.支付成功后返回商家回調頁面--------->會傳回很多Alipay傳回來的參數,很多明文,防止別人攻擊
13.返回商家的同時請求后台服務器------>發送這些參數給后台
14.接收參數並且驗證,成功則創建訂單支付對象返回訂單號,否則提示支付失敗
配置秘鑰
1.注冊成為螞蟻金服開放平台用戶 https://openhome.alipay.com
2.點擊登陸，二維碼登陸或者密碼登陸.
3.登陸成功后，點擊開發中心里面的研發服務。
4。進入研發服務后在沙箱應用中，點級設置應用密鑰（在網上查找RSA簽名驗簽工具windows_V1.4）中復制 RSA簽名驗簽工具.bat 生成密鑰 密鑰格式選擇非java適用 長度選2048（私鑰比公鑰安全，因為私鑰相當於一把只有你自己有的鑰匙，防止密碼泄露等）
5。復制公鑰到SA2(SHA256)密鑰(推薦）中的查看應用公鑰。並保存
6.設置成功后點擊查看應用公鑰或者支付公鑰，是否設置成功。
7.在公鑰.text中，需要把text中的自己生成的公鑰修改成https://openhome.alipay.com/platform/appDaily.htm?tab=info頁面中RSA(SHA1)密鑰的查看支付寶公鑰。
瀏覽歷史（我的足跡）
一般看瀏覽歷史是因為我在沒有加入購物車或者收藏時，我很想買那一件商品，所以看瀏覽歷史。
對於商城項目中的歷史瀏覽記錄我們將它儲存在redis緩存中,便於存儲和拿取數據,
而我們首先要明確歷史記錄什么時候添加,什么時候獲取。
添加 訪問商品詳情頁面的時候,需要添加歷史瀏覽記錄
獲取 訪問用戶中心個人信息頁的時候,需要獲取歷史記錄
便於用戶查看瀏覽的頁面。
消息推送：
python websocket Django 實時消息推送
概述：
WebSocket 是什么？
WebSocket 是 HTML5 提供的一種瀏覽器與服務器間進行全雙工通訊的協議。依靠這種協議可以實現客戶端和服務器端 ，一次握手，雙向實時通信。
WebSocket是一種在單個TCP連接上進行全雙工通信的協議
WebSocket使得客戶端和服務器之間的數據交換變得更加簡單，允許服務端主動向客戶端推送數據。在WebSocket API中，瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接，並進行雙向數據傳輸
現在，很多網站為了實現推送技術，所用的技術都是輪詢。輪詢是在特定的的時間間隔（如每1秒），由瀏覽器對服務器發出HTTP請求，然后由服務器返回最新的數據給客戶端的瀏覽器。這種傳統的模式帶來很明顯的缺點，即瀏覽器需要不斷的向服務器發出請求，然而HTTP請求可能包含較長的頭部，其中真正有效的數據可能只是很小的一部分，顯然這樣會浪費很多的帶寬等資源。
而比較新的技術去做輪詢的效果是Comet。這種技術雖然可以雙向通信，但依然需要反復發出請求。而且在Comet中，普遍采用的長鏈接，也會消耗服務器資源。
在這種情況下，HTML5定義了WebSocket協議，能更好的節省服務器資源和帶寬，並且能夠更實時地進行通訊
1. http協議是用在應用層的協議，他是基於tcp協議的，http協議建立鏈接也必須要有三次握手才能發送信息。
http鏈接分為短鏈接，長鏈接，短鏈接是每次請求都要三次握手才能發送自己的信息。即每一個request對應一個response。長鏈接是在一定的期限內保持鏈接。保持TCP連接不斷開。客戶端與服務器通信，必須要有客戶端發起然后服務器返回結果。客戶端是主動的，服務器是被動的。
2. WebSocket
WebSocket他是為了解決客戶端發起多個http請求到服務器資源瀏覽器必須要經過長時間的輪訓問題而生的，他實現了多路復用，他是全雙工通信。在webSocket協議下客服端和瀏覽器可以同時發送信息。
建立了WenSocket之后服務器不必在瀏覽器發送request請求之后才能發送信息到瀏覽器。這時的服務器已有主動權想什么時候發就可以發送信息到服務器。而且信息當中不必在帶有head的部分信息了與http的長鏈接通信來說，這種方式，不僅能降低服務器的壓力。而且信息當中也減少了部分多余的信息。
WebSocket 服務端：
用的是 dwebsocket,安裝命令pip install dwebsocket.
這是客戶端的一些說明,在客戶端,websocket的兩個屬性：readyState和bufferedAmount,區別和說明如下:
根據readyState屬性可以判斷webSocket的連接狀態，該屬性的值可以是下面幾種：
0 ：對應常量CONNECTING (numeric value 0)，
正在建立連接連接，還沒有完成。The connection has not yet been established.
1 ：對應常量OPEN (numeric value 1)，
連接成功建立，可以進行通信。The WebSocket connection is established and communication is possible.
2 ：對應常量CLOSING (numeric value 2)
連接正在進行關閉握手，即將關閉。The connection is going through the closing handshake.
3 : 對應常量CLOSED (numeric value 3)
連接已經關閉或者根本沒有建立。The connection has been closed or could not be opened.
根據bufferedAmount可以知道有多少字節的數據等待發送，若websocket已經調用了close方法則該屬性將一直增長。
WebSocket 和HTTP的區別：
HTTP：每發一次廣告，就請求一次。
webSocket: 請求一次，可以多次發送。
項目部署：
我的項目是部署到docker(容器)上面。
Docker 簡介
Docker 是一個開源項目，誕生於 2013 年初，最初是 dotCloud 公司內部的一個業余項目。它基於 Google 公司推出的 Go 語言實現。 項目后來加入了 Linux 基金會，遵從了 Apache 2.0 協議，項目代碼在 GitHub 上進行維護。
Docker 自開源后受到廣泛的關注和討論，以至於 dotCloud 公司后來都改名為 Docker Inc。Redhat 已經在其 RHEL6.5 中集中支持 Docker；Google 也在其 PaaS 產品中廣泛應用。
Docker 項目的目標是實現輕量級的操作系統虛擬化解決方案。 Docker 的基礎是 Linux 容器（LXC）等技術。在 LXC 的基礎上 Docker 進行了進一步的封裝，讓用戶不需要去關心容器的管理，使得操作更為簡便。用戶操作 Docker 的容器就像操作一個快速輕量級的虛擬機一樣簡單。
為什么用docker？
作為一種新興的虛擬化方式，Docker 跟傳統的虛擬化方式相比具有眾多的優勢。
Docker 在如下幾個方面具有較大的優勢：
更快速的交付和部署
Docker在整個開發周期都可以完美的輔助你實現快速交付。Docker允許開發者在裝有應用和服務本地容器做開發。可以直接集成到可持續開發流程中。
例如：開發者可以使用一個標准的鏡像來構建一套開發容器，開發完成之后，運維人員可以直接使用這個容器來部署代碼。 Docker 可以快速創建容器，快速迭代應用程序，並讓整個過程全程可見，使團隊中的其他成員更容易理解應用程序是如何創建和工作的。 Docker 容器很輕很快！容器的啟動時間是秒級的，大量地節約開發、測試、部署的時間。
高效的部署和擴容
Docker 容器幾乎可以在任意的平台上運行，包括物理機、虛擬機、公有雲、私有雲、個人電腦、服務器等。 這種兼容性可以讓用戶把一個應用程序從一個平台直接遷移到另外一個。
Docker的兼容性和輕量特性可以很輕松的實現負載的動態管理。你可以快速擴容或方便的下線的你的應用和服務，這種速度趨近實時。
更高的資源利用率
Docker 對系統資源的利用率很高，一台主機上可以同時運行數千個 Docker 容器。容器除了運行其中應用外，基本不消耗額外的系統資源，使得應用的性能很高，同時系統的開銷盡量小。傳統虛擬機方式運行 10 個不同的應用就要起 10 個虛擬機，而Docker 只需要啟動 10 個隔離的應用即可。
更簡單的管理
使用 Docker，只需要小小的修改，就可以替代以往大量的更新工作。所有的修改都以增量的方式被分發和更新，從而實現自動化並且高效的管理。
虛擬機（VM(VMware)）與docker的區別 ：
VM(VMware)在宿主機器、宿主機器操作系統的基礎上創建虛擬層、虛擬化的操作系統、虛擬化的倉庫，然后再安裝應用；
Docker容器，在宿主機器、宿主機器操作系統上創建Docker引擎，在引擎的基礎上再安裝應用。
docker設計小巧，部署遷移快速，運行高效，應用之間相互獨立，管理人員可以看到所有容器的內容，虛擬化技術比較臃腫，不論什么應用都需要先創建新的系統，並且並非按照應用隔離，而是按照系統隔離，管理員無法看到系統內部信息 舉個例子，Docker就是手機中的各種APP，只需要一個系統就可以下載自己所需的應用，但是虛擬化技術相當於你的蘋果手機安裝一個龐大軟件，這個軟件上安裝安卓系統、魅族系統等，每個系統上還要安裝各類應用，比較麻煩。 但兩者沒有絕對的好壞，主要還是看應用場景，根據不同的需求選擇不同的解決方案即可。