美多商城項目總結

註冊

通常來講，註冊模塊並無什麼難點，但我在註冊模塊中寫了兩種驗證碼（普通驗證碼，短信驗證碼），普通驗證碼沒有難度，但手機驗證碼須要在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，只須要一個系統就能夠下載本身所需的應用，可是虛擬化技術至關於你的蘋果手機安裝一個龐大軟件，這個軟件上安裝安卓系統、魅族系統等，每一個系統上還要安裝各種應用，比較麻煩。 但二者沒有絕對的好壞，主要仍是看應用場景，根據不一樣的需求選擇不一樣的解決方案便可。