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