如何實現(xiàn)掃描支付二維碼支付成功后進入指定功能頁面

Dreamweaver中實現(xiàn)掃描二維碼支付，支付成功后進入指定功能頁面，通常需要以下幾個步驟：

1.
生成二維碼：首先，你需要生成一個包含支付信息的二維碼。這通常涉及到后端服務，它會根據(jù)支付請求生成一個二維碼圖片，并將支付信息存儲在服務器上。
2.
用戶掃描二維碼：用戶使用微信或其他支付應用掃描二維碼，完成支付。
3.
支付狀態(tài)回調：支付完成后，支付平臺會向你的服務器發(fā)送一個支付成功的回調通知。這個通知通常包含支付結果和訂單信息。
4.
服務器處理回調：你的服務器接收到支付成功的回調后，需要驗證回調信息的合法性，并更新訂單狀態(tài)為已支付。
5.
頁面跳轉：一旦訂單狀態(tài)更新為已支付，服務器可以生成一個包含支付成功信息的頁面，并通過HTTP重定向或AJAX請求將用戶引導到這個頁面。

在Dreamweaver中，你可以使用HTML、CSS和JavaScript來創(chuàng)建用戶界面，并通過AJAX與服務器進行交互。以下是一個簡化的示例流程：

HTML頁面：創(chuàng)建一個包含二維碼的HTML頁面，用戶可以掃描這個二維碼進行支付。

服務器端處理：在服務器端，你需要編寫代碼來處理支付回調，并在支付成功后更新訂單狀態(tài)，并生成一個支付成功的頁面。

頁面跳轉：在支付成功后，服務器返回的頁面中可以包含一個JavaScript代碼，用于在支付成功后自動跳轉到指定的功能頁面。

請注意，這只是一個簡化的示例，實際的實現(xiàn)可能會更復雜，需要考慮安全性、用戶體驗和錯誤處理等因素。此外，具體的實現(xiàn)細節(jié)會根據(jù)你使用的支付平臺和后端技術棧有所不同。在實際開發(fā)中，你可能需要查閱支付平臺的開發(fā)文檔，了解如何生成二維碼、處理支付回調以及如何與前端頁面進行交互。有需要完整源碼的朋友，加關注線下溝通。

附：代碼僅供需要的朋友參考（為便于展示顯示圖片效果）

支付成功后，微信異步回調頁面為notify_wxpay.php,在根目錄中,可根據(jù)情況修改

微信支付功能開發(fā)

、介紹

電商購物系統(tǒng)。使用Python作為主要開發(fā)語言，前端采用HTML、CSS、BootStrap等技術實現(xiàn)界面，后端采用Django作為開發(fā)框架。實現(xiàn)一個電商購物系統(tǒng)。用戶可以登錄、注冊、查看商品、添加購物車、購買商品、查看訂單、評論等。管理員可以編輯用戶和商品信息。

二、系統(tǒng)展示圖片

三、演示視頻 and 代碼 and 介紹

視頻+代碼+介紹：電商購物 · 語雀

四、Django介紹

Django 是一個開源的、基于 Python 的 web 框架。它的主要目標是使得 Web 開發(fā)更加快速、更簡單，同時還要保證代碼的可重用性和可維護性。以下是 Django 的一些主要特點：

MTV 架構：Django 遵循 MTV（Model-Template-View）設計模式，這與經(jīng)典的 MVC（Model-View-Controller）模式有些許不同。在 Django 中，Model 代表數(shù)據(jù)模型，Template 是負責展示的部分，而 View 負責處理用戶請求并返回響應。
DRY 原則：Django 遵循 “Don't Repeat Yourself” (DRY) 原則，鼓勵代碼的重用。
自帶管理界面：Django 包括一個自動生成的、為內容管理定制的管理界面，只需很少的代碼即可完成。
ORM：Django 自帶了一個強大的 ORM（對象關系映射）系統(tǒng)，可以輕松地與多種數(shù)據(jù)庫進行交互，同時還支持數(shù)據(jù)庫的遷移。
安全性：Django 有內置的防護措施，如跨站腳本攻擊（XSS）、跨站請求偽造（CSRF）和 SQL 注入等。
中間件支持：Django 的中間件系統(tǒng)允許開發(fā)者在處理請求和響應的過程中插入自定義的處理方法。

以下是一個簡單的 Django 項目和應用的示例代碼：

創(chuàng)建一個新的 Django 項目：

django-admin startproject myproject

進入項目目錄并創(chuàng)建一個新的 Django 應用：

cd myproject
python manage.py startapp myapp

定義模型 (在 myapp/models.py 中)：

from django.db import models

class Article(models.Model):
    title=models.CharField(max_length=200)
    content=models.TextField()
    pub_date=models.DateTimeField('date published')

    def __str__(self):
        return self.title

在 myproject/settings.py 中添加 'myapp' 到 INSTALLED_APPS 列表：

INSTALLED_APPS=[
    ...
    'myapp',
    ...
]

遷移數(shù)據(jù)庫：

python manage.py makemigrations myapp
python manage.py migrate

創(chuàng)建一個簡單的視圖 (在 myapp/views.py 中)：

from django.http import HttpResponse
from .models import Article

def index(request):
    articles=Article.objects.all()
    output=', '.join([a.title for a in articles])
    return HttpResponse(output)

配置 URL (在 myapp/urls.py 中)：

from django.urls import path
from . import views

urlpatterns=[
    path('', views.index, name='index'),
]

在 myproject/urls.py 中連接應用的 URLs：

from django.contrib import admin
from django.urls import path, include

urlpatterns=[
    path('admin/', admin.site.urls),
    path('articles/', include('myapp.urls')),
]

運行開發(fā)服務器：

python manage.py runserver

當您訪問 127.0.0.1:8000/articles/，您應該會看到數(shù)據(jù)庫中所有文章的標題（如果有的話）。

程背景介紹

每年的春節(jié)是中國人的傳統(tǒng)節(jié)日，大多數(shù)中國人都會在這一天選擇回家團聚。為了方便用戶進行購票，2012 年春節(jié)，鐵道部推出 12306 網(wǎng)站，進行網(wǎng)絡實名購票。然而，歷年春節(jié)假期，巨大的訪問請求都讓中國鐵路客戶服務中心網(wǎng)站（www.12306.cn）陷入“萬劫不復”。根據(jù)新浪的調查，在 2013 年春節(jié)，有近 90%的網(wǎng)友表示 12306 網(wǎng)站緩慢、頁面崩潰，嚴重影響正常購票。

世界級的人口遷徙帶來了一個世界級的難題：要如何通過網(wǎng)絡，把火車票及時賣給有需要的人？

鐵道部在線車票發(fā)售網(wǎng)站 12306 基本不存在大量圖片、視頻這些占帶寬資源的東西，所面臨的主要問題就是數(shù)據(jù)庫的高并發(fā)量——用中國的人口基數(shù)來算，這是一個極為恐怖的并發(fā)量，在車票發(fā)售的高峰時間點，向 12306 發(fā)起的并發(fā)請求數(shù)量大得就像一場國家規(guī)模的 DDOS 攻擊。

12306 網(wǎng)站所面臨的問題分析：

中國鐵路客戶服務中心網(wǎng)站（www.12306.cn）是世界規(guī)模最大的實時交易系統(tǒng)之一，媲美 Amazon.com，節(jié)假日尤其是春節(jié)的訪問高峰，網(wǎng)站壓力巨大。據(jù)統(tǒng)計，在 2012 年初的春運高峰期間，每天有 2000 萬人訪問該網(wǎng)站，日點擊量最高達到 14 億。

而到了 2013 年春節(jié)期間，12306 的網(wǎng)站訂票系統(tǒng)系統(tǒng)峰值負載達 2.6 萬 QPS（每秒鐘 2.6 萬次訪問請求）或 11 萬 TPS（TPS 指每秒服務器處理、傳輸?shù)氖挛锾幚韨€數(shù)，一條消息輸入、一條消息輸出、一次數(shù)據(jù)庫訪問，均可以折算成 TPS），與 2012 淘寶雙 11 活動峰值負載基本相當。

所以 12306 所面臨的難題本質上也是屬于高并發(fā)訪問問題，類似與一些電商網(wǎng)站所搞的"秒殺"活動一樣。通過對 12306 的深度優(yōu)化，2015 年 12306網(wǎng)站順利過關，沒有“癱瘓”，是值得慶祝的。而我們本次課題主要就是來探究一下如何對 12306 網(wǎng)站做深度優(yōu)化來抵御高并發(fā)訪問。

高并發(fā)訪問

那么 12306 做了什么樣的優(yōu)化，才解決了高并發(fā)訪問呢?

12306 技術部主任單杏花在接受一次記者采訪的時候有說到：我們研發(fā)了分布式的內存計算的余票計算技術，讓余票計算變得非常高效。與此同時單杏花及其團隊還研發(fā)了異步交易排隊系統(tǒng)，這種系統(tǒng)采用售取分離、讀寫分離的核心系統(tǒng)架構等多種技術，為 12306 售票系統(tǒng)提供技術支撐。

其實通過她的描述，我們可以得出一些處理高并發(fā)訪問方式：

采用內存計算（使用緩存系統(tǒng)）
異步處理請求（進行流量消峰）
數(shù)據(jù)庫進行讀寫分離操作
常見的分布式緩存系統(tǒng)：MongoDB ， Redis，MemCache

流量消峰的方案

要對流量進行削峰，最容易想到的解決方案就是用消息隊列來緩沖瞬時流量，把同步的直接調用轉換成異步的間接推送，中間通過一個隊列在一端承接瞬時的流量洪峰，在另一端平滑地將消息推送出去。在這里，消息隊列就像“水庫”一樣，攔蓄上游的洪水，削減進入下游河道的洪峰流量，從而達到減免洪水災害的目的。

進行答題

你是否還記得，最早期的秒殺只是純粹地刷新頁面和點擊購買按鈕，它是后來才增加了答題功能的。那么，為什么要增加答題功能呢？這主要是為了增加購買的復雜度，從而達到兩個目的。

第一個目的是防止部分買家使用秒殺器在參加秒殺時作弊。2011 年秒殺非常火的時候，秒殺器也比較猖獗，因而沒有達到全民參與和營銷的目的，所以系統(tǒng)增加了答題來限制秒殺器。增加答題后，下單的時間基本控制在 2s 后，秒殺器的下單比例也大大下降。答題頁面如下圖所示。

第二個目的其實就是延緩請求，起到對請求流量進行削峰的作用，從而讓系統(tǒng)能夠更好地支持瞬時的流量高峰。這個重要的功能就是把峰值的下單請求拉長，從以前的 1s 之內延長到 2s~10s。

這樣一來，請求峰值基于時間分片了。這個時間的分片對服務端處理并發(fā)非常重要，會大大減輕壓力。而且，由于請求具有先后順序，靠后的請求到來時自然也就沒有庫存了，因此根本到不了最后的下單步驟，所以真正的并發(fā)寫就非常有限了。

分時間段進行產(chǎn)品上架處理

其實處理高并發(fā)訪問還有兩種常見手段：靜態(tài)化、集群

靜態(tài)化: 分布式緩存是為了解決數(shù)據(jù)庫服務器和 Web 服務器之間的瓶頸，如果一個網(wǎng)站流量很大這個瓶頸將會非常明顯，每次數(shù)據(jù)庫查詢耗費的時間將不容樂觀。對于更新速度不是很快的站點，可以采用靜態(tài)化來避免過多的數(shù)據(jù)查詢，可使用 Freemaker 或 Velocity 來實現(xiàn)頁面靜態(tài)化。

集群: 使用多臺服務器去處理并發(fā)請求

系統(tǒng)架構介紹

基于以上幾點高并發(fā)的處理方案，我們本次所設計的 12306 后端系統(tǒng)架構如下所示。

數(shù)據(jù)同步架構

系統(tǒng)管理員通過后臺管理系統(tǒng)基于一些基礎數(shù)據(jù)（座位數(shù)據(jù)，列車車次數(shù)據(jù)，乘車計劃數(shù)據(jù)）生成指定日期的乘車計劃數(shù)據(jù)。然后我們通過 logstash將生成的數(shù)據(jù)同步到 ES 和 Redis 中。

Logstash 常見的數(shù)據(jù)獲取方式拉，推。上述架構給大家展示的是拉的模式，但是這種方式我們當前這個系統(tǒng)環(huán)境中不太適合，原因是因為我們使用了 MyCat 進行分庫分表的處理，而 Logstash 在進行拉取數(shù)據(jù)的時候如果數(shù)據(jù)量較大我們就需要進行分頁拉取，那么此時 Logstash 就會生成類似這樣的一條 sql 語句：select count(*) as `count` from ....來查詢滿足條件總條數(shù)，但是這個 count 別名使用了反引號，而這個反引號在 MyCat 中無法使用，因此就會產(chǎn)生異常。

因此本次我們在進行數(shù)據(jù)同步的時候使用的是 Logstash 的推模式進行數(shù)據(jù)同步，如下所示：

數(shù)據(jù)搜索架構

數(shù)據(jù)同步完畢以后，用戶就可以搜索相關的乘車計劃數(shù)據(jù)了。具體的搜索架構如下所示：

用戶下單架構

通常訂票系統(tǒng)要處理生成訂單、減扣庫存、用戶支付這三個基本的階段，我們系統(tǒng)要做的事情是要保證火車票訂單不超賣、不少賣，每張售賣的車票都必須支付才有效，還要保證系統(tǒng)承受極高的并發(fā)。

這種方案也就是單杏花主任所提出的異步交易排隊系統(tǒng)。當然 12306 網(wǎng)站的還有一個改造的關鍵技術建立可伸縮擴展的云應用平臺。

根據(jù)互聯(lián)網(wǎng)上的新聞，中國鐵道科學研究院電子計算技術研究所副所長，12306 網(wǎng)站技術負責人朱建生說，為了應對 2015 年春運售票高峰，該網(wǎng)站采取 5 項措施：

利用外部云計算資源分擔系統(tǒng)查詢業(yè)務，可根據(jù)高峰期業(yè)務量的增長按需及時擴充。
對系統(tǒng)的互聯(lián)網(wǎng)接入帶寬進行擴容，并可根據(jù)流量情況快速調整，保證高峰時段旅客順暢訪問網(wǎng)站。
防范惡意搶票，通過技術手段屏蔽搶票軟件產(chǎn)生的惡意流量，保證網(wǎng)站健康運行，維護互聯(lián)網(wǎng)售票秩序。
制定了多套應急預案，以應對突發(fā)情況。

用戶下單

下單流程

下單頁面

注意：下單之前需要初始化一些用戶數(shù)據(jù)到 Redis 中(train_manager:userInfo)，默認用戶已經(jīng)登錄下單頁面：12306\otn\confirmPassenger\initDc.html

訂單服務實現(xiàn)

下單接口定義

實體類創(chuàng)建

訂單工程環(huán)境搭建

導入下單工程（itheima-train-manager-order）
在 nacos 配置中心中添加配置項（itheima-train-manager-order-dev.yml）

下單接口定義

Nginx 配置

反向代理配置

# 下單服務的代理轉發(fā)地址
upstream train-manager-order {
server 127.0.0.1:9056 ;
}
# 配置下單工程的反向代理
server {
listen 80;
server_name www.trainmanager.order.com;
access_log logs/host.access.order.log main ; # nginx 訪問日志
location / {
proxy_pass http://train-manager-order ;
}
error_page 500 502 503 504 /50x.html;
location=/50x.html {
root html;
}
}

在 hosts 文件中配置 www.trainmanager.order.com 域名映射

Nginx 限流配置

為了防止一些搶票助手所發(fā)起的一些無用請求，我們可以使用 nginx 中的限流策略進行限流操作。

常見的限流算法：計數(shù)器、漏桶算法、令牌桶算法

計數(shù)器限流算法

計數(shù)器法是限流算法里最簡單也是最容易實現(xiàn)的一種算法。比如我們規(guī)定，對于 A 接口來說，我們 1 分鐘的訪問次數(shù)不能超過 100 個。那么我們可以設置一個計數(shù)器 counter，其有效時間為 1 分鐘（即每分鐘計數(shù)器會被重置為 0），每當一個請求過來的時候，counter 就加 1，如果 counter的值大于 100，就說明請求數(shù)過多；如下圖所示：

這個算法雖然簡單，但是有一個十分致命的問題，那就是臨界問題。

如下圖所示，在 1:00 前一刻到達 100 個請求，1:00 計數(shù)器被重置，1:00 后一刻又到達 100 個請求，顯然計數(shù)器不會超過 100，所有請求都不會被攔截；然而這一時間段內請求數(shù)已經(jīng)達到 200，遠超 100。

漏桶算法

漏桶算法其實很簡單，可以粗略的認為就是注水漏水過程，往桶中以一定速率流出水，以任意速率流入水，當水超過桶流量則丟棄，因為桶容量是不變的，保證了整體的速率。如下圖所示：

令牌桶算法

令牌桶是一個存放固定容量令牌的桶，按照固定速率 r 往桶里添加令牌；桶中最多存放 b 個令牌，當桶滿時，新添加的令牌被丟棄；當一個請求達到時，會嘗試從桶中獲取令牌；如果有，則繼續(xù)處理請求；如果沒有則排隊等待或者直接丟棄；可以發(fā)現(xiàn)，漏桶算法的流出速率恒定，而令牌桶算法的流出速率卻有可能大于 r；

從作用上來說，漏桶和令牌桶算法最明顯的區(qū)別就是是否允許突發(fā)流量(burst)的處理，漏桶算法能夠強行限制數(shù)據(jù)的實時傳輸（處理）速率，對突發(fā)流量不做額外處理；而令牌桶算法能夠在限制數(shù)據(jù)的平均傳輸速率的同時允許某種程度的突發(fā)傳輸。

Nginx 的限流策略

Nginx 的限流主要是兩種方式：限制訪問頻率和限制并發(fā)連接數(shù)。

Nginx 按請求速率限速模塊使用的是漏桶算法，即能夠強行保證請求的實時處理速度不會超過設置的閾值。

Nginx 官方版本限制 IP 的連接和并發(fā)分別有兩個模塊：

limit_req_zone：用來限制單位時間內的請求數(shù)，即速率限制 , 采用的漏桶算法 "leaky bucket"。
limit_conn_zone：用來限制同一時間連接數(shù)，即并發(fā)限制。

limit_req_zone

limit_conn_zone

使用語法：limit_conn_zone key zone

key ：定義限流對象，binary_remote_addr 是一種 key，表示基于 remote_addr(客戶端 IP) 來做限流，binary_ 的目的是壓縮內存占用量。
zone：定義共享內存區(qū)來存儲訪問信息， myRateLimit:10m 表示一個大小為 10M，名字為 myRateLimit 的內存區(qū)域。1M 能存儲 16000 IP 地址的訪問信息，10M 可以存儲 16W IP 地址訪問信息。

生成訂單

預扣庫存

分配座位

具體的實現(xiàn)步驟如下所示：

獲取所有的指定座位類型的所有車廂的 key（集合）
遍歷集合獲取每一個車廂數(shù)據(jù)（集合）
遍歷集合獲取每一個座位所對應的狀態(tài)值
狀態(tài)值如果是 0，記錄座位標號
更改座位狀態(tài)值

具體的代碼實現(xiàn)如下所示：

生成訂單

為了提高數(shù)據(jù)響應速度，我們在構建訂單數(shù)據(jù)的時候可以使用一個線程來完成。并且在該線程執(zhí)行完畢以后，要獲取執(zhí)行結果，因此這個任務類我們需要使用 Callable，執(zhí)行這個任務的線程我們可以使用線程池來完成。具體的實現(xiàn)步驟如下所示：

創(chuàng)建雪花算法對應的類對象
創(chuàng)建線程池對象
獲取指定日期的乘車計劃數(shù)據(jù)，并將其封裝到一個 TbRidingPlanDate 對象中
生成訂單

具體的代碼實現(xiàn)如下所示：

Redis 排隊

采用 Redis 中的 ZSet 集合存儲排隊信息，使用：列車編號 + 乘車日期 + 用戶 id 作為 key，使用當前系統(tǒng)時間的納秒值作為 value

同步 ES 庫存

發(fā)送同步數(shù)據(jù)

那么我們首先來完成一下生產(chǎn)者的代碼，具體的步驟如下所示：

定義要同步的數(shù)據(jù)的 JavaBean

添加消息隊列的相關配置

nacos 配置中心添加 rabbitmq 的配置信息

RabbitmqConfiguration 配置類添加如下配置

定義發(fā)送數(shù)據(jù)的 service（直接復制 itheima-train-manager 工程中的 RabbitmqProducer）
更改 OrderService 構建 OrderSynEs 對象，發(fā)送同步數(shù)據(jù)

接收同步數(shù)據(jù)

接下來我們就需要在 itheima-train-manager-es 同步數(shù)據(jù)工程中來接收同步數(shù)據(jù)，更新 ES 的庫存信息。具體的實現(xiàn)步驟如下所示：

在 RabbitmqConfiguration 配置類添加如下配置：

在 EsConsumer 類中添加監(jiān)聽同步庫存隊列的方法，方法代碼邏輯如下所示

ESIndexService 類添加如下方法：

發(fā)送訂單數(shù)據(jù)

實現(xiàn)思路

按照我們最初的想法，我們只需要將訂單 Order 對象發(fā)送到 Mq 中，然后訂單處理服務從隊列中監(jiān)聽到 Order 數(shù)據(jù)生成訂單即可。但是我們后續(xù)還有另外一個操作，就是在下單成功以后，我們需要將下單狀態(tài)通過 websocket 推送給用戶，因此我們需要在訂單處理服務中不單單需要獲取到訂單數(shù)據(jù)，還需要獲取到用戶的數(shù)據(jù)。因此在發(fā)送下單數(shù)據(jù)的時候單單發(fā)送訂單的數(shù)據(jù)時不夠的。我們需要創(chuàng)建一個實體類，用來封裝訂單以及該訂單所對應的用戶數(shù)據(jù)（OrderHandler）。

代碼實現(xiàn)

具體的實現(xiàn)步驟如下所示：

創(chuàng)建實體類(OrderHandler)（用于封裝發(fā)送給 MQ 的訂單數(shù)據(jù)）

RabbitmqConfiguration 配置類添加如下配置

更改 OrderService 發(fā)送訂單數(shù)據(jù)

查詢排隊接口

當用戶下單完畢以后，就會跳轉到下單成功頁面。那么在下單成功頁面就需要調用查詢排隊接口，去查詢排隊信息。

接口定義

業(yè)務邏輯實現(xiàn)

訂單數(shù)據(jù)庫架構

訂單數(shù)據(jù)特點：寫并發(fā)量大于讀并發(fā)量

如何提高我們寫數(shù)據(jù)的能力，給用戶良好的用戶體驗，就是我們需要研究的目標！

設計方向：

多個節(jié)點進行數(shù)據(jù)寫入
進行讀寫分離操作，提高單節(jié)點寫數(shù)據(jù)的并發(fā)能力
要保證每一個寫入節(jié)點的高可用，當主節(jié)點出現(xiàn)問題以后，從節(jié)點立馬升級為主節(jié)點

基于以上幾點的設計思路，我們所設計出來的訂單數(shù)據(jù)庫的架構如下所示：

MySql 主從復制

主從復制簡介

就是有兩個數(shù)據(jù)庫服務器，一個是主（master）數(shù)據(jù)庫服務器，另一個是從（slave）數(shù)據(jù)庫服務器。當主（master）數(shù)據(jù)庫有數(shù)據(jù)寫入，包括插入、刪除、修改，都會在從（slave）數(shù)據(jù)庫上操作一次。這樣的操作下，主從（slave）數(shù)據(jù)庫的數(shù)據(jù)都是一樣的，就相當于時刻在做數(shù)據(jù)備份，就算主（master）數(shù)據(jù)庫的數(shù)據(jù)全部丟失了，還有從（slave）數(shù)據(jù)庫的數(shù)據(jù)，我們就可以把從（slave）數(shù)據(jù)庫的數(shù)據(jù)導出來進行數(shù)據(jù)恢復

主從復制原理

主從復制原理主要有三個線程不斷在工作：

1、主（master）數(shù)據(jù)庫啟動 bin 二進制日志，這樣會有一個 Dump 線程，這個線程是把主（master）數(shù)據(jù)庫的寫入操作都會記錄到這個 bin 的二進制文件中。

2、然后從（slave）數(shù)據(jù)庫會啟動一個 I/O 線程，這個線程主要是把主（master）數(shù)據(jù)庫的 bin 二進制文件讀取到本地，并寫入到中繼日志（Relay log）文件中。

3、最后從（slave）數(shù)據(jù)庫其他 SQL 線程，把中繼日志（Relay log）文件中的事件再執(zhí)行一遍，更新從（slave）數(shù)據(jù)庫的數(shù)據(jù)，保持主從數(shù)據(jù)一致。

一主一從介紹

一主一從部署

在 Mycat 中，讀寫分離可以說有兩種：一種是一主一從，另一種是多主多從。接下來我們就來首先給大家介紹一下一主一從的部署。分為兩步進行實現(xiàn)：

一主一從的數(shù)據(jù)庫配置實現(xiàn)
MyCat 一主一從實現(xiàn)讀寫分離配置

一主一從的 MySql 部署步驟如下所示：

在指定的目錄下創(chuàng)建對應的文件夾（做 mysql 容器的目錄映射）

將 docker 中的 mysql 配置文件分別復制到 mysql10/config 和 mysql11/config 目錄中
對兩個節(jié)點的配置文件（/usr/local/mysql-master-slave/mysql10/config/mysql.conf.d）做如下配置：

在線咨詢

上一篇：真的更安全？QQ同步助手網(wǎng)頁版改掃碼登錄
下一篇：開發(fā)你的酷炫裝備 Jetson TX1使用指南

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯(lián)系。

整合營銷服務商