美团饿了么外卖返利小程序公众号搭建外卖返利分销系统代cps源码

外卖CPS小程序源码分享

饿了么、美团优惠开发(外卖cps,三级裂变源码)

源码或搭建

/

截图

功能列表

特价电影票

饿了么外卖（3个红包）

美团外卖

美团优选（1分钱买菜）

购物返利（淘宝，拼多多，京东）

话费优惠充值（92折，慢充）

火车票优惠

滴滴打车优惠

小程序广告收益（流量主）

公众号绑定

更多功能…

作者联系方式

交流交流感情也好呀~

代搭建，源码都可以出，好谈~

转介绍，代理，都行，作者不会亏待你~

步骤

下载以上源代码到本地

/

修改为你自己的微信小程序，打开 /dist/pages/ele/index.js

微信小程序->开发管理->开发设置 添加 request的域名： 地址：

https://mp./wxamp/devprofile/get_profile?token=271531762&lang=zh_CN

小程序管理后台配置你的链接

后台地址： 进去之后选择小程序管理->无裂变小程序管理->添加小程序->填入你自己的链接

微信开发者工具，导入项目，提交审核

没用的代码, 请忽略

概念

主从复制，是指将一台 Redis 服务器的数据，复制到其他的Redis服务器。

前者称为主节点 (master/leader)，后者称为从节点 (slave/follower)，数据的复制是单向的，只能由主节点到从节点。

Master以写为主，Slave以读为主。

默认情况下，每台 Redis 服务器都是主节点，且一个主节点可以有零个或多个从节点，但一个从节点只能由一个主节点。

主从复制，读写分离.

作用

数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式；

故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障回复；实际上是一种服务的冗余；

负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写 Redis 数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个节点分担读负载，可以大大提高Redis服务器的并发量；

高可用（集群）基石：除了上述作用意外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将 Redis 运用于工程项目中，只是用一台 Redis 是万万不能的（宕机），原因如下：

从结构上，单个 Redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大；

从容量上，单个 Redis 服务器内存容量有限，就算一台 Redis 服务器内存容量为 256GB，也不能将所有内存用作 Redis 存储内存，

一般来说，单台 Redis 最大使用内存不应该超过 20GB。

环境配置

只配置从库，不用配置主库

127.0.0.1:6379> info replication

Replication

role:master # 角色： master

connected_slaves:0 #没有从机

master_replid:0d064ffd4a54a85fdd85637328e88d4abd05d8ac

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:0

second_repl_offset:-1

repl_backlog_active:0

repl_backlog_size:1048576

repl_backlog_first_byte_offset:0

repl_backlog_histlen:0

127.0.0.1:6379>

复制代码

因为我这里只用了一台服务器，所以我们配置一个伪集群环境，修改对应配置信息

port：进程占用端口号；

pidfile：记录进程的 ID，文件带有锁，可以防止程序的多次启动；

logfile：明确日志文件位置；

dbfilename：持久化文件位置

修改配置信息后，根据配置文件分别启动三个 Redis 服务

一主二从

默认情况下（配置前），每台 Redis 服务器都是主节点；

只配置从库，不用配置主库

认主人：一主（6379）二从（6380、6381）

主机能读写，从机只能读不能写

重要！！！

如果主节点服务器有密码，作为从节点的服务器，要在配置文件中加入

masterauthxxx(主节点连接密码)

复制代码

如：

6380端口的服务器，配置文件 redis80.conf，搜索配置参数 masterauth，修改为

masterauth 6379

复制代码

配置前：

127.0.0.1:6380> info replication

Replication

role:master

connected_slaves:0

master_replid:f89b7907749c026069c80059a9d2cd41fae23e39

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:0

second_repl_offset:-1

repl_backlog_active:0

repl_backlog_size:1048576

repl_backlog_first_byte_offset:0

repl_backlog_histlen:0

复制代码

使用命令方式配置从机

命令 主机地址 主机端口

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379

OK

复制代码

从机配置后信息：

127.0.0.1:6380> info replication

Replication

role:slave

master_host:127.0.0.1

master_port:6379

master_link_status:up

master_last_io_seconds_ago:10

master_sync_in_progress:0

slave_repl_offset:14

slave_priority:100

slave_read_only:1

connected_slaves:0

master_replid:2382336ee0bd6abe27c267b35c827bcecbb3fa91

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:14

second_repl_offset:-1

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:1

repl_backlog_histlen:14

复制代码

主机信息：

127.0.0.1:6379> info replication

Replication

role:master

connected_slaves:1 # 多了从机的信息

slave0:ip=127.0.0.1,port=6380,state=online,offset=798,lag=1

master_replid:2382336ee0bd6abe27c267b35c827bcecbb3fa91

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:798

second_repl_offset:-1

repl_backlog_active:1

repl_backlog_size:1048576

repl_backlog_first_byte_offset:1

repl_backlog_histlen:798

复制代码

配置文件配置从机

真实的从主配置应该在配置文件中配置，这样才是永久的。我们这里使用的是命令来配置，是暂时的。

查看作为从节点的配置文件：

配置主机的ip地址、端口号，这时启动服务器就是从节点的存在；

主机的密码

主机断开

主机服务器关闭，从机仍然存在，只是连接状态 master_link_status 变为 down。

当主机服务器再启动时，主从关系仍然存在。

从机断开

1号从机断开，再启动后，1号从机变为新主机（没有在配置文件配置主机信息，之前使用的是命令的方式建立主从关系）；

当1号从机再次和主机建立主从关系后，在1号从机断开期间，主机新写入的数据，1号从机仍然能够查询到。

复制原理

Slave 启动成功连接到 master 后会发送一个 sync 同步命令

Master 接收到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件到 slave，并完成一次完全同步；

全量复制： 而 Slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中；

增量复制： Master 继续将新的所有手机到的修改命令一次传给 Slave，完成同步；

但是只要是重新连接 Master，一次完全同步（全量复制）将被自动执行！

糖葫芦模式

A：主机；

B：从机；

C：从机；

A作为B的主机，B做C的主机。这时 B 在某种意义上来讲，既是从机又是主机，但是使用命令 info replication可以看到 B 仍是从机，它 只能读不能写。

主从复制一直存在一个问题，那就是当主机宕机了，那么它的所有从机都没有多少意义了，它们只能读不能写，无法存储新的数据；

那么能不能，当主机宕机后，在它的从机里面选一个出来作为主机呢？

谋朝篡位

手动

当主机不存在了，我们选一个从机，手动输入命令：

SLAVEOF no one

复制代码

使该从机变为主机，再手动操作其他从机，连接到最新的这个主节点。

SLAVEOF 127.0.0.1 6388

复制代码

哨兵模式

主从切换技术的方法：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式。Redis 从 2.8 开始正式提供了 Sentinel(哨兵)架构来解决这个问题。

谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

原理

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。

其原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行中的多个 Redis 实例。

这里的哨兵有两个作用：

通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器；

当哨兵监测到 Master 宕机，会自动将某个 Slave 切换成 Master，然后通过发布订阅通知其他的从服务器，修改配置文件，让他们切换主机。

多哨兵模式

一个哨兵进程对 Redis 服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主机宕机了，哨兵1 先检测到这个结果，系统并不会马上进行 failover （故障转移）过程，仅仅是哨兵1 主观认为主服务器不可用，这个现象是主观下线；

当后面的哨兵也监测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票由一个哨兵发起，进行 failover（故障转移）操作；

切换成功后，就会通过 发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线。

配置

创建 sentinel.conf 文件

配置信息

sentinel monitor 哨兵名称 监测主机IP地址 端口号 定值（当多少个哨兵监测到主机主观下线，才进行 failover 操作）

sentinel monitor myredis 127.0.0.1 6379 1

如果主机存在登录密码，需要配置以下信息

sentinel auth-pass 哨兵名称 主机密码（注意：因为哨兵不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同。）

sentinel auth-pass myredis 243600

复制代码

启动 redis-sentinel

[root@wrkq1njujislh7mx redis]# ./bin/redis-sentinel sentinel.conf

复制代码

模拟主机宕机

现在我们将主机关闭

127.0.0.1:6379> shutdown

not connected> exit

[root@wrkq1njujislh7mx redis]#

复制代码

再观察一下它的两个从机的状态（这里尽量快一点，不然哨兵就已经更换主机了）

等待片刻，我们可以看到 哨兵的日志文件发生变化：

此时，哨兵已经选好了新的主机，端口号为6380的Redis服务器，我们再次查看下6380和6381的服务器的状态：

此时新的主从机关系已经重新建立了，那么，如果之前那个主机6379再次回来了呢？

[root@wrkq1njujislh7mx redis]# ./bin/redis-server redis79.conf

[root@wrkq1njujislh7mx redis]# ./bin/redis-cli -p 6379 -a 243600

Warning: Using a password with ‘-a’ or ‘-u’ option on the command line interface may not be safe.

127.0.0.1:6379> ping

PONG

复制代码

查看服务器状态（我这里命令输入慢了，快一点的话可以看到，此时的服务器还是Master，等到哨兵反应过来了，该服务器才变为从机的）

此时的服务器自动变为了6380的从机，哨兵模式的规则。

127.0.0.1:6379> info replication

Replication

role:slave

master_host:127.0.0.1

master_port:6380

master_link_status:down

master_last_io_seconds_ago:-1

master_sync_in_progress:0

slave_repl_offset:1

master_link_down_since_seconds:1628239308

slave_priority:100

slave_read_only:1

connected_slaves:0

master_replid:6de2947f7c68080c6bce977a0b4fca378ceb982b

master_replid2:0000000000000000000000000000000000000000

master_repl_offset:0

second_repl_offset:-1

repl_backlog_active:0

repl_backlog_size:1048576

repl_backlog_first_byte_offset:0

repl_backlog_histlen:0

复制代码

查看哨兵日志：

优点

哨兵集群，基于主从复制，所有的主从配置优点，它都包含了；

主从可以切换，故障可以转移，系统的可用性就会更好；

哨兵模式就是主从复制模式的升级，手动到自动，整个架构更加健壮。

缺点

Redis 不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦；

实现哨兵模式的配置复杂繁琐（以上的配置信息，只是哨兵模式运行起来的简单配置）