項目流程

web應用模式

• 前後端不分離

• ![enter descriptio

• 前後端分離

• ![enter description here][2]

• 在前後端分離的應用模式中，我們通常將後端開發的每個視圖都稱爲一個接口，或者API，前端通過訪問接口來對數據進行增刪改查。

RESTful

• 即Representational State Transfer的縮寫，國內大部分人理解爲“表現層狀態轉化”
• RESTful是一種開發理念， REST是設計風格而不是標準， 描述的是在網絡中client和server的一種交互形式；REST本身不實用，實用的是如何設計 RESTful API（REST風格的網絡接口）

RESTful架構總結：

• 每一個URL代表一種資源
• 客戶端和服務器之間，傳遞這種資源的某種變現層
• 客戶端通過四個HTTP動詞，對服務器端資源進行操作，實現‘變現層狀態轉化’

RESTful設計方法

使用Django開發REST接口

REST接口開發的核心任務

- 將請求的數據（如json格式）轉換爲模型類對象
- 操作數據庫
- 將模型類對象轉換爲響應的數據（如json）

序列化Serializer

• 將程序中的一個數據結構類型轉換爲其他格式（字典、JSON、XML等），例如將Django中的模型類對象裝換爲JSON字符串，這個轉換過程我們稱爲序列化。

Django REST framework

• 是一個用於構建Web API 的強大而又靈活的工具， 簡稱：DRF

DRF特點

提供了定義序列化器Serializer的方法，可以快速根據 Django ORM 或者其它庫自動序列化/反序列化；
提供了豐富的類視圖、Mixin擴展類，簡化視圖的編寫；
豐富的定製層級：函數視圖、類視圖、視圖集合到自動生成 API，滿足各種需要；
多種身份認證和權限認證方式的支持；
內置了限流系統；
直觀的 API web 界面；
可擴展性，插件豐富

DRF工程搭建

環境安裝與配置

• DRF是以Django擴展應用的方式提供的，所以我們可以直接利用已有的Django環境而無需從新創建。（若沒有Django環境，需要先創建環境安裝Django）
• 安裝DRF：pip install djangorestframework
• 添加rest_framework應用：在setting.py中的INSTALLED_APPS添加‘rest_framework’

DRF

• 1、創建序列化器
  – model：指明該序列化器處理的數據字段從模型類BookInfo參考生成
  – fields 指明該序列化器包含模型類中的哪些字段，'all’指明包含所有字段
• 2、編寫視圖
• • queryset 指明該視圖集在查詢數據時使用的查詢集
• • serializer_class 指明該視圖在進行序列化或反序列化時使用的序列化器
• 定義路由
• 運行測試

serializer 序列化器

定義serializer

• 定義方法：使用類來定義，須繼承自rest_framework.serializers.Serializer。
  注意：serializer不是隻能爲數據庫模型類定義，也可以爲非數據庫模型類的數據定義。
• 創建serializer對象： Serializer(instance=None, data=empty, * * kwargs)
• • 用於序列化時，將模型類對象傳入instance參數
• • 用於反序列化時，將要被反序列化的數據傳入data參數
• • 除了instance和data參數外，在構造Serializer對象時，還可通過context參數額外添加數據,

序列化使用

• 首先查詢出一個對象
• 構造序列化器對象
• 獲取序列化器數據
• 如果要被序列化的是包含多條數據的查詢集QuerySet，可以通過添加many=True參數補充說明

反序列化使用

驗證

• 在獲取反序列化的數據前，必須調用is_valid()方法進行驗證，驗證成功返回True，否則返回False。

三種方法補充定義驗證行爲

• validate 對<field_name>字段進行驗證
• 在序列化器中需要同時對多個字段進行比較驗證時，可以定義validate方法來驗證
• 在字段中添加validators選項參數，也可以補充驗證行

保存

如果在驗證成功後，想要基於validated_data完成數據對象的創建，可以通過實現create()和update()兩個方法來實現。

模型類序列化器ModelSerializer

如果我們想要使用序列化器對應的是Django的模型類，DRF爲我們提供了ModelSerializer模型類序列化器來幫助我們快速創建一個Serializer類

• 基於模型類自動生成一系列字段
• 基於模型類自動爲Serializer生成validators
• 包含默認的create()和update()的實現

model 指明參照哪個模型類

fields 指明爲模型類的哪些字段生成

美多商城

項目準備

• 在git平臺創建工程
• 添加前端文件
• 創建DRF工程
• 創建數據庫

配置

• 修改settings/dev.py 文件中的路徑信息
• 在INSTALLED_APPS中添加rest_framework
• 設置數據庫，並在meiduo_mall的__init__文件中添加：pymysql.install_as_MySQLdb()、
• 安裝django-redis，並在settings中配置
• 設置本地化語言與時區
• 設置log日誌
• 新建utils/exceptions.py，定義異常處理的函數，並在配置文件中添加異常處理的配置

用戶部分

用戶模型類

• 在apps中創建Django應用users，並在配置文件中註冊users應用
• 創建完應用後執行數據庫的遷移
• 注意：Django建議我們對於AUTH_USER_MODEL參數的設置一定要在第一次數據庫遷移之前就設置好，否則後續使用可能出現未知錯誤。

註冊

接口分析

• 圖片驗證碼
• 短信驗證碼
• 用戶名判斷是否存在
• 手機號判斷是否存在
• 註冊保存用戶數據
  圖片驗證碼、短信驗證碼考慮到後續可能會在其他業務中也用到，因此我們將圖片驗證碼獨立，創建一個新應用verifications，在此應用中實現圖片驗證碼、短信驗證碼。
  圖片驗證碼後端接口設計：
  訪問方式：GET/image——codes/(?p<image_code_id>[\w-]+)/
  請求參數：路徑參數
  image_code_id, 類型：uuuid字符串，（圖片驗證碼編號）
  返回數據：驗證碼圖片

短信驗證碼

業務處理流程

• 檢查圖片驗證碼
• 檢查是否在60s內有發送記錄
• 生成短信驗證碼
• 保存短信驗證碼與發送記錄
• 發送短信

後端接口設計

• 訪問方式:GET /sms_codes/(?P1[3-9]\d{9})/?image_code_id=xxx&text=xxx
• 請求參數：路徑參數與查詢字符串參數
• mobile, image_code_id, text.
• 返回數據：json；返回值：message；
• 在vertifications定義序列化器：ImageCodeCheckSerializer用以校驗；因要校驗驗證碼編號以及客戶端輸入的text所以要定義validate方法用以校驗

跨域CORS

• 因爲前後端分別設置了不同的域名，此處使用CORS來解決後端對跨域訪問的支持；使用django-cors-headers擴展
• 在setting中添加應用以及中間層設置；添加白名單
• CORS_ALLOW_CREDENTIALS = True # 允許攜帶cookie；指明在跨域訪問中，後端是否支持對cookie的操作

使用celery發送短信

• 在meiduo_mall下創建celery_tasks用以保存celery異步任務；
• 在celery_tasks文件夾下創建config文件，保存celery的配置信息
• 再創建main.py文件用作celery的啓動文件
• 創建sms目錄，並在sms文件夾下創建tasks文件，用以保存發送短信的異步任務
• 在驗證碼應用中的views文件中改寫SMSCodeView視圖，使用celery異步任務發送短信

判斷賬號是否存在

判斷用戶名是否存在：

• 請求方式：GET usernames/(?P\w{5,20})/count/
• 請求參數：路徑參數；username
• 返回數據：json；返回值：username，count

判斷手機號是否存在

• 方式和判斷用戶名一樣

註冊

接口設計：

• 請求方式：POST/users/
• 請求參數JOSN或表單
• 參數：username；password； password2； sms_code；mobile， allow（是否同意用戶協議）
• 返回數據：JSON； id， username, mobile

JWT(Json web token)

在用戶註冊或登錄後，我們想記錄用戶的登錄狀態，或者爲用戶創建身份認證的憑證。我們不再使用Session認證機制，而使用Json Web Token認證機制。

• session認證所顯露的問題，
• • session是保存在內存中的，隨着用戶的增多，服務端的開銷會明顯增大
• • 擴展性：用戶認證之後，服務端做認證記錄，如果認證的記錄被保存在內存中的話，這意味着用戶下次請求還必須要請求在這臺服務器上,這樣才能拿到授權的資源，這樣在分佈式的應用上，相應的限制了負載均衡器的能力。這也意味着限制了應用的擴展能力。
• • 因爲是基於cookie來進行用戶識別的, cookie如果被截獲，用戶就會很容易受到跨站請求僞造的攻擊。

基於token的鑑權機制

token必須要在每次請求時傳遞給服務端，它應該保存在請求頭裏

• JWT是由三段信息構成的，將這三段信息文本用.鏈接一起就構成了Jwt字符串
• 第一部分頭部：header，第二部分荷載：payload，第三部分：簽證（signature）
  總結：
• 優點：因爲json的通用性，所以JWT是可以進行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。
  因爲有了payload部分，所以JWT可以在自身存儲一些其他業務邏輯所必要的非敏感信息。
  便於傳輸，jwt的構成非常簡單，字節佔用很小，所以它是非常便於傳輸的。
  它不需要在服務端保存會話信息, 所以它易於應用的擴展
• 安全相關：不應該在jwt的payload部分存放敏感信息，因爲該部分是客戶端可解密的部分。
  保護好secret私鑰，該私鑰非常重要。
  如果可以，請使用https協議

Django REST framework JWT

關於簽發和核驗JWT，我們可以使用Django REST framework JWT擴展來完成

• 安裝djangorestframework-jwt，並在配置文件中配置，
• JWT_AUTH = {
  ‘JWT_EXPIRATION_DELTA’: datetime.timedelta(days=1),
  }，JWT_EXPIRATION_DELTA 指明token的有效期

登錄

業務說明： 驗證用戶名和密碼，驗證成功後，爲用戶簽發JWT，前端將簽發的JWT保存下來。
後端接口設計：

• 請求方式：POST/authorizations/
• 請求參數：json或表單；參數：username，password
• 返回數據：JSON，username， user_id， token

Django REST framework JWT提供了登錄簽發JWT的視圖，可以直接使用

但是默認的返回值僅有token，我們還需在返回值中增加username和user_id。
from rest_framework_jwt.views import obtain_jwt_token

urlpatterns = [
url(r’^authorizations/$’, obtain_jwt_token),
]
通過修改該視圖的返回值可以完成我們的需求。

QQ登錄

![enter description here][3]

創建模型類

創建新應用：oauth，總路由前綴：oauth/

• 在meiduo_mall/utils/models.py文件中創建模型類基類，用以增加數據新建時間和更新時間；
• 在oauth/models.py中定義QQ身份（openid）與用戶模型類User的關聯關係
  openid = models.CharField(max_length=64, verbose_name=‘openid’, db_index=True)
• 進行數據庫的遷移

返回qq登錄網址的視圖

qq登錄回調處理

綁定用戶身份接口

業務邏輯：
用戶需要填寫手機號、密碼、圖片驗證碼、短信驗證碼
如果用戶未在美多商城註冊過，則會將手機號作爲用戶名爲用戶創建一個美多賬戶，並綁定用戶
如果用戶已在美多商城註冊過，則檢驗密碼後直接綁定用戶
處理流程：
![enter description here][4]

用戶個人信息中心

郵件與驗證

使用django發送郵件

django中內置了郵件的發送功能， 被定義在django.core.mail模塊中； 發送郵件需要使用SMTP服務器

• 使用django發送郵件：
  django.core.mail模塊提供了send_mail來發送郵件
  send_mail(subject, message, from_email, recipient_list,html_message=None)
• subject 郵件標題
  message 普通郵件正文， 普通字符串
  from_email 發件人
  recipient_list 收件人列表
  html_message 多媒體郵件正文，

保存郵件併發送驗證郵件

• 在保存郵箱的時候，需要向用戶發送驗證郵件，我們將發送郵件的工作放到celery中異步執行。
• 在celerytasks目錄中新建email目錄和email/_init.py文件和email/tasks.py文件

收貨地址

業務邏輯

省市區地址的數據庫建立與查詢
用戶地址的增刪改查處理
設置默認地址
設置地址標題

省市區聯動：

在用戶錄入地址時，需要進行省市區的選擇。在頁面加載時，向後端請求省份數據，當用戶選擇確定省份後，向後端請求該省份的城市數據；在用戶選擇確定城市數據後，向後端請求該城市的區縣信息。我們把這個過程稱爲省市區三級聯動。
- 新建一個應用areas來實現省市區三級聯動。
- 在area/models中以子關聯的方式創建數據庫表，子關聯字段的外鍵指向自身，所以Foreignkey(‘self"’)
- 遷移到數據庫中後，將area.sql中數據導入到數據庫中
- 此時可以創建一個腳本，在script中創建import_areas_data_to_db.sh文件，將遷移命令寫入腳本中，再爲文件添加可執行權限，執行腳本文件即可
- 創建完模型類，並進行數據庫遷移後，在areas/serializers.py文件中新建序列化器
- 在views.py文件中新建視圖
- 定義路由
- 在前端文件中修改user_center_site.py文件，增加vue變量，並新建user_center_site.js文件

使用緩存

因爲省市區的數據是經常被用戶查詢使用的，而且數據基本不變，所以可以將此數據進行緩存處理，減少數據庫的查詢次數

• djangoREST framework中使用緩存，可以通過drf-extention擴展來實現
• 首先進行安裝：pip install drf-extention
• 使用rest_frame_work_extention.cache.decorators中的cache_response裝飾器來裝飾返回數據的類視圖的對象方
  ···python
  class CityView(views.APIView):
  @cache_response()
  def get(self, request, *args, **kwargs):
  …
  cache_response可以接受兩個參數

用戶地址管理

爲了保存y用戶的地址信息，在models中定義模型類

• 在views中添加視圖
• 在serializers中創建序列化器
• 在users/urls.py中添加路由
• 在前端修改user_center_site.js文件

商品部分

數據表的設計

SPU和SKU

• SPU是商品信息聚合的最小單位，是一組可服用、易檢索的標準化信息的集合，該集合描述了一個產品的特性。通俗的講，屬性值、特性相同的商品就可以稱爲一個SPU。
• SKU即庫存進出計量的單位，可以是以件、盒、托盤等爲單位，是物理上不可分割的最小存貨單元。在使用時要根據不同業態，不同管理模式來處理。在服裝、鞋類商品中使用最多最普遍。
• 常見新的應用goods，並在models文件中創建新的商品數據模型類
• 創建新的廣告內容應用contents， 以及創建廣告數據模型類

FastDFS分佈式文件系統

FastDFS 是用 c 語言編寫的一款開源的分佈式文件系統。FastDFS 爲互聯網量身定製， 充分考慮了冗餘備份、負載均衡、線性擴容等機制，並注重高可用、高性能等指標，使用 FastDFS 很容易搭建一套高性能的文件服務器集羣提供文件上傳、下載等服務。

• 包含Tracker server 和Storage server，客戶端請求Tracker Server進行文件 上傳和下載，通過Tracker Server進行調度最終由Storage server完成文件的上傳和下載

使用Docker進行安裝

• 鏡像：鏡像是構建 Docker 的基石。用戶基於鏡像來運行自己的容器。鏡像也是 Docker 生命周 期中的“構建”部分。鏡像是基於聯合文件系統的一種層式結構，由一系列指令一步一步構 建出來
• Docker容器：一個鏡像格式; 一些列標準操作; 一個執行環境。

使用Docker安裝FastDFS

• 1、獲取鏡像
• 2、運行Tracker：執行命令開啓
• 3、運行Storage：執行命令開啓
• 注意：如果無法重新運行，可以刪除/var/fdfs/storage/data目錄下的fdfs_storaged.pid 文件，然後重新運行storage

使用FastDFS客戶端，需要有配置文件。在meiduo_mall/utils目錄下新建fastdfs目錄，client.conf配置文件放到這個目錄中。

• 上傳文件需要先創建fdfs_client.client.Fdfs_client的對象，並指明配置文件
• 通過創建的客戶端對象執行上傳文件的方法

自定義文件存儲器

• 需要繼承自django.core.files.storage.Storage
• 支持Django不帶任何參數來實例化存儲類，也就是說任何設置都應該從django.conf.settings中獲取
• 存儲類中必須實現_open()和_save()方法，以及任何後續使用中可能用到的其他方法。
• 需要爲存儲類添加django.utils.deconstruct.deconstructible裝飾器
• 在meiduo_mall/utils/fastdfs目錄中創建fdfs_storage.py文件，實現可以使用FastDFS存儲文件的存儲類
• 在Django配置中設置自定義文件存儲類，在settings/dev.py文件中添加設置
• 在/etc/hosts中添加訪問FastDFS storage服務器的域名

CKEditor富文本編輯器

富文本即具備豐富樣式格式的文本。

• 安裝
• 在配置文件中添加應用
• 添加CKEditor設置
• 在總路由中添加ckeditor路由
• 爲模型類添加字段

頁面靜態化

頁面靜態化即將動態渲染生成的頁面結果保存成html文件，放到靜態文件服務器中。用戶訪問的時候訪問的直接是處理好之後的html靜態文件。

• 在廣告內容應用contents中，新建crons.py文件
• 在配置文件中添加保存靜態文件的目錄
• 在meiduo_mall 中新建templates模板目錄，配置模板目錄， 並在模板目錄中新建index.html模板文件
• 在前端js目錄中新建index.js文件

定時任務

通過django-crontab擴展來實現定時任務

• 安裝
• 添加應用
• 在配置文件中設置定時執行的時間

靜態化首頁的手動腳本

在scripts中新建靜態化首頁的腳本regenerate_index_html.py，併爲文件增加可執行權限

商品詳情頁

品詳情頁的靜態化由運營人員在編輯商品信息時觸發生成靜態化頁面，
先來實現靜態化異步任務，在celery_tasks中新建html/tasks.py任務
生成靜態商品詳情頁面

• 商品分類菜單
• 獲取當前sku的信息
• 麪包屑導航信息中的頻道
• 構建當前商品的規格鍵
• 獲取 當前商品的所有sku
• 構建不同規格參數（規格）的sku字典
• 獲取當前商品的規格信息
• 若當前sku的規格信息不完整， 則不再繼續
• 渲染模板，生成靜態html文件
• 將形成商品類別部分的數據封裝成一個公共函數，放在goods/utils.py中
  獲取商城商品分類菜單
• 商品頻道及分類菜單
• 使用有序字典保存類別的順序

用戶瀏覽歷史記錄

歷史記錄只需保存多個商品的sku_id即可，而且需要保持添加sku_id的順序，所以採用redis中的列表來保存，

• 在配置文件中增加瀏覽歷史記錄的redis配置
• 在users/serializers.py中實現序列化器
• users/views.py文件中編寫視圖
• 前端實現
  查看歷史記錄
• 在users/views.py中UserBrowsingHistoryView視圖補充get方法
• 修改前端代碼

商品列表頁

獲取商品列表數據

• 在meiduo_mall/utils中創建pagination.py文件，在其中創建分頁配置類
• 在配置文件中設置REST framework分頁使用的分頁類
• 在goods/views.py中實現視圖
• REST framework提供了對於排序的支持，使用REST framework提供的OrderingFilter過濾器後端即可。
  OrderingFilter過濾器要使用ordering_fields 屬性來指明可以進行排序的字段有哪些。

商品搜索

我們引入搜索引擎來實現全文檢索。全文檢索即在指定的任意字段中進行檢索查詢。

• 開源的 Elasticsearch 是目前全文搜索引擎的首選。
• 使用Docker安裝Elasticsearch及其擴展
• 獲取鏡像，修改elasticsearch的配置文件 elasticsearc-2.4.6/config/elasticsearch.yml第54行，更改ip地址爲本機ip地址，創建docker容器運行
• 使用haystack對接Elasticsearch
• 安裝
• 註冊應用
• 在配置文件中配置haystack使用的搜索引擎後端
• HAYSTACK_SIGNAL_PROCESSOR 的配置保證了在Django運行起來後，有新的數據產生時，haystack仍然可以讓Elasticsearch實時生成新數據的索引
• 創建索引類，在goods應用中新建search_indexes.py文件，用於存放索引類
• 在templates目錄中創建text字段使用的模板文件
• 手動生成初始索引
• 創建序列化器
• 創建視圖
• 定義路由
• 測試

購物車部分

• 在用戶登錄和未登錄的情況下，都可以保存用戶的購物信息
• 用戶可以對購物車進行增刪改查
• 用戶對於購物車數據的勾選也要保存，在訂單結算頁面會使用勾選數據
• 用戶登錄時，合併cookie中的購物車數據到redis中
• 對於未登錄的用戶，購物車數據使用瀏覽器cookie保存
• 對於登錄的用戶，購物車數據在後端使用redis保存

購物車數據存儲

• 在配置文件中增加用於保存購物車的Redis配置
• 在cookie中只能保存字符串數據，所以將上述數據使用pickle進行序列化轉換 ，並使用base64編碼爲字符串，保存到cookie中。

pickle模塊的使用

pickle模塊是python的標準模塊，提供了對於python數據的序列化操作，可以將數據轉換爲bytes類型，其序列化速度比json模塊要高。

• pickle.dumps() 將python數據序列化爲bytes類型
• pickle.loads() 將bytes類型數據反序列化爲python的數據類型
  python標準庫中提供了base64模塊，用來進行轉換
• base64.b64encode() 將bytes類型數據進行base64編碼，返回編碼後的bytes類型
• base64.b64deocde() 將base64編碼的bytes類型進行解碼，返回解碼後的bytes類型

添加到購物車

因爲前端可能攜帶cookie，爲了保證跨域請求中，允許後端使用cookie

• 創建新的應用carts
• 在carts/serializers.py文件中創建序列化器

查詢購物車數據

• 創建新的序列化器
• 修改views視圖，增加get方法

修改購物車數據

修改視圖，添加put方法

刪除 購物車數據

• 新建序列化器
• 修改視圖，增加delete方法

購物車全選

• 新建序列化器
• 在views文件中新建視圖

登錄合併購物車

在用戶登錄時，將cookie中的購物車數據合併到redis中，並清除cookie中的購物車數據。
普通登錄和QQ登錄都要合併，所以將合併邏輯放到公共函數裏實現。
在carts/utils.py中創建merge_cart_cookie_to_redis方法

• 修改視圖函數，重寫類視圖裏的post方法來添加合併邏輯
• 修改路徑urls
• 修改qq登錄視圖

訂單部分

• 創建訂單應用orders，編輯模型類models.py

訂單結算

• 在serializers文件中新建序列化器
• 在視圖文件中編寫視圖函數

保存訂單

• 在orders/views中創建視圖
• 創建序列化器

保存訂單的思路

• 獲取當前下單的用戶
• 生成訂單編號
• 保存訂單基本信息數據orderInfo
• 從redis中獲取購物車結算的商品數據
• 遍歷結算商品
  - 判斷商品庫是否充足
  - 減少商品庫存，增加商品銷量
  - 保存訂單商品數據
  - 在redis’購物車中刪除已計算商品數據

數據庫事務

在保存訂單數據中，涉及到多張表（OrderInfo、OrderGoods、SKU）的數據修改，對這些數據的修改應該是一個整體事務，即要麼一起成功，要麼一起失敗。
併發處理：

• 悲觀鎖
• 樂觀鎖
• 任務隊列
  使用樂觀鎖改寫下單邏輯
  修改MySQL的事務隔離級別

支付寶支付

創建新的應用payment

使用沙箱環境來模擬支付環境
支付流程
![enter description here][5]

接入步驟：

• 創建應用
• 配置密鑰
• 搭建和配置開發環境
• 接口調用

配置密鑰

• 生成應用的私鑰和公鑰
• 保存應用私鑰文件
  • 在payment應用中新建keys目錄，用來保存祕鑰文件。
  • 將應用私鑰文件app_private_key.pem複製到payment/keys目錄下。
• 查看公鑰 ：cat app_publict_key.pem. 並將公鑰複製給支付寶
• 保存支付寶公鑰

發起支付

• 首先創建視圖
• 在配置文件中編輯支付寶的配置信息

保存支付結果

• 用戶支付成功後，支付寶會將用戶重定向到http://www.meiduo.site:8080/pay_success.html，並攜帶支付結果數據
• 前端頁面將此數據發送給後端，後端檢驗並保存支付結果

Xadmin

xadmin是Django的第三方擴展，可是使Django的admin站點使用更方便。

• 安裝
• 在配置文件中註冊應用
• xadmin有建立自己的數據庫模型類，需要進行數據庫遷移
• 在總路由中添加xadmin的路由信息

用戶權限限制

在產品運營平臺中，是需要對用戶進行權限控制的。Django實現了用戶權限的控制

數據庫讀寫分離

Mysql主從同步

• 主從同步定義
  主從同步使得數據可以從一個數據庫服務器複製到其他服務器上，在複製數據時，一個服務器充當主服務器（master），其餘的服務器充當從服務器（slave）。因爲複製是異步進行的，所以從服務器不需要一直連接着主服務器，從服務器甚至可以通過撥號斷斷續續地連接主服務器。通過配置文件，可以指定複製所有的數據庫，某個數據庫，甚至是某個數據庫上的某個表。
• 主從同步的好處
  • 主從同步使得數據可以從一個數據庫服務器複製到其他服務器上，在複製數據時，一個服務器充當主服務器（master），其餘的服務器充當從服務器（slave）。因爲複製是異步進行的，所以從服務器不需要一直連接着主服務器，從服務器甚至可以通過撥號斷斷續續地連接主服務器。通過配置文件，可以指定複製所有的數據庫，某個數據庫，甚至是某個數據庫上的某個表。
  • 提高數據安全，因爲數據已複製到從服務器，從服務器可以終止複製進程，所以，可以在從服務器上備份而不破壞主服務器相應數據
    提高數據安全，因爲數據已複製到從服務器，從服務器可以終止複製進程，所以，可以在從服務器上備份而不破壞主服務器相應數據
  • 在主服務器上生成實時數據，而在從服務器上分析這些數據，從而提高主服務器的性能
• 配置主從的步驟
  • 在主服務器上，必須開啓二進制日誌機制和配置一個獨立的ID
  • 在每一個從服務器上，配置一個唯一的ID，創建一個用來專門複製主服務器數據的賬號
  • 在開始複製進程前，在主服務器上記錄二進制文件的位置信息
  • 如果在開始複製之前，數據庫中已經有數據，就必須先創建一個數據快照（可以使用mysqldump導出數據庫，或者直接複製數據文件）
  • 配置從服務器要連接的主服務器的IP地址和登陸授權，二進制日誌文件名和位置
• 詳細配置主從同步
  • 獲取mysql的鏡像，主從同步儘量保證多臺mysql的版本相同，運行mysql docker鏡像，
  • 備份主服務器原有數據到從服務器
  • 配置主服務器master（Ubuntu中的MySQL）
  • 配置從服務器slave （docker中的mysql）

配置Django實現數據庫讀寫分離

django在進行數據庫操作的時候，讀取數據與寫數據（增、刪、改）可以分別從不同的數據庫進行操作

• 在配置文件中增加slave數據庫的配置
• 創建數據庫操作的路由分發類
• 在配置文件中增加讀寫分離路由

項目部署

靜態文件

當Django運行在生產模式時，將不再提供靜態文件的支持，需要將靜態文件交給靜態文件服務器。

• 將front_end_pc中的講臺文件和django自帶的靜態文件，集中到靜態服務器中，創建目錄static
• 使用Nginx服務器作爲靜態文件服務器
• 重啓Nginx服務器

動態接口

在項目中複製開發配置文件dev.py 到生產配置prod.py，並修改該文件

• django的程序通常使用uwsgi服務器來運行
• 先進行安裝
• 創建uwsgi配置文件：uwsgi.ini
• 啓動uwsgi服務器，
• 修改Nginx配置文件，讓Nginx接收到請求後轉發到uwsgi服務器
• 重啓nginx