title: mybatis plus版本冲突导致的异常
date: 2021-02-16 19:09:00
tags: dubbo,nacos

错误信息

Caused by: java.lang.NoClassDefFoundError: org/mybatis/logging/LoggerFactory at com.baomidou.mybatisplus.extension.spring.MybatisSqlSessionFactoryBean.(MybatisSqlSessionFactoryBean.java:98) at com.cy.ares.dao.conf.MybatisConfiguration.sqlSessionFactoryBean(MybatisConfiguration.java:151)

原因

mybatis JAR包冲突。去掉你的 mybatis-spring-boot-starter。

但是在某个项目的引入中并没有发现maven中有导入mybatis-spring-boot-starter。那么需要排查导入的包中是否有包含mybatis JAR包。方法：使用命令mvn dependency:tree 树状结构查看所有引入的jar包。然后搜索mybatis-spring-boot-starter包。找出该父级包，使用exclusion属性排除mybatis-spring-boot-starter包的导入。

title: 为什么没人在乎你的会员权益？搭建会员体系这些坑，你都避开了吗？
date: 2021-02-16 19:09:00
tags: dubbo,nacos

会员，最初始的本质是享受特权，享受特有的优惠与福利，而所谓的“会员权益”正是“会员体系”能够长期存在的最大助力与基石。

从长期来看，平台的一切会员运营手段均是为了盈利而服务的，但短期来说，则目标各有不同。而这些目标，也恰好是搭建会员权益体系的原因：

• 注重用户体验，提升用户粘性；
• 培养用户对产品的忠诚度；
• 便于构建用户画像，方便进行后期精细化管理；
• 从会员群体中获取更多商业价值
• 促进用户转化

……

不同的目的，决定着最终构建出的会员权益的侧重点如何，例如：

1、如果以提升用户粘性为主，那么会员权益中则需要侧重服务类型权益。通过会员体系的建立，筛选出较高等级的会员，给与其减免费用、优先应答、专人服务等权益。如此可在尽量少的成本下，得到更好的效果，用户也会为了更高级的服务而提升自己等级；

2、 如果以商业价值为主，那么会员权益中可以提供实物或虚拟商品为主，通过利益诱导，吸引其在平台下单转化，同时消耗积分，会员等级越高，花费则越少。

你能给会员提供的价值是什么？

你能给会员提供什么？24小时客服、98折、会员日福利？很多企业在设置会员权益之时，都陷入了一个怪圈——不管有没有用，权益显得越多越好。

实际上，这类拍脑袋定出来的会员权益存在着三大问题：

1. 没有重点。会员权益宜精不宜多，列出太多反而没有重点；

2. 权益过于普通。例如生日积分奖励、直邮杂志、购物折扣等等，用户在被各类优惠反复轰炸的今天，太过普通的权益无法对会员产生吸引力；

3. 权益不明确。“生日贺礼”是什么？是高端生日礼品还是电子贺卡？“高端圈层活动”又是什么？都是些什么人参加？什么主题？此类权益会让会员觉得莫名其妙，反而产生反作用。

因此，在搭建会员权益体系之前，你需要确定好你能给用户提供的价值（不仅仅指权益内容）是什么。而确定这个，可以通过问自己以下几个问题来解决：

• 你所在的平台可以提供或者置换到哪些资源或者服务？写张表格，把它们和对接人一起列出来；

• 这些权益中，成本是多少？通过成本的关系，将它们排列出来，划定等级；

• 摆在你面前的这张表格里，有没有哪些资源或服务是对用户真正有用的？把自己代入用户视角，并把这些没用的资源剔除；

• 能否把这些权益包装一下，打包或者取一个比较吸引人的名字？或者使用其他方法，让这些权益的价值看起来更加大；

• 最后一点，这些权益是否会对实现平台短期目标有帮助？是否会产生被刷单薅羊毛等反作用？

如何设计一套诱人的会员权益？

1、以最高层级诉求优先对标

既然会员体系本身就是为了满足高价值用户，设计权益，应该先从头部用户开始，和非头部用户相比，头部用户需求度、产品了解度、挑剔度都比较高，满足了头部用户的权益，也就验证了权益设计的成功。

2、围绕核心动作设计权益

所谓的核心动作，就是用户为获得产品价值所做出的的动作，也是企业最希望用户完成的动作。交易类产品核心动作是下单，在线内容的核心动作是观看内容。不论增值还是降低成本，设计权益需始终以促进核心动作的发生为目标。如，电商权益折扣、无理由退货，都为了让用户下单更爽，而电商企业可以获得更多收入。

3、合理控制权益成本

权益成本越高，权益价值吸引力一般也越大，一般的硬权益，需要花费较高的成本。但如果权益过高，会员的利润就会降低。所以，通常在做权益预算时，需要考虑这两个问题：

1. 现有的预算能否满足会员增长
2. 权益的ROI如何

4、简单直接，不过分花哨

一般一个会员体系有1个硬权益就会有效果，为了便于用户理解及记忆，一般来说，权益不宜过多，主打1-2个硬权益即可，适度增加一些额外权益，后续在做会员的心智教育时，让用户更聚焦地感知会员价值，为拉新和会员忠诚服务。

5、权益要设置一定的区隔

没有比较就没有伤害，比较会加剧价值感，会员对不同层级的权益比较，也会影响价值感。付费会员体系中，如付费和免费差异不大，用户就不会购买。在设计权益时，让差异感尽可能拉大，在高层级中提供专属层级权益，凸显会员、尤其是高等级会员的价值感。

我们来举个例子：

趣悠悠是一家趣味民宿在线预订平台，通过卖定价788元的会员卡，3个月覆盖全国20多个目的地，我们来看看是怎么设计的：

以足够吸引力的价格，让利给客户，降低住宿门槛。客户只需付 788 元，即可获得市价为 300-2000 元/间夜的轻奢型民宿 6 晚的权益。客户在「住一晚即可回本」的刺激下，很容易做出购买决定。

这里面既围绕了核心动作设计权益，吸引用户快速下单。又解决了淡季民宿无人问津的问题，也很好的控制了ROI。

再看一家，正善牛肉是如何设置会员卡等级的：

正善牛肉做过多次不同方案后，最终确定将付费会员卡设为3个等级，价格越高，可享受的权益越多、越实惠。

等级一：28元超级会员双日卡，购买享会员价；

等级二：178元超级会员月卡，购买享会员价和包邮；

等级三：999元超级会员年卡，购买享社群内专享商品享折上折、包邮、随时退服务。

付费会员卡的定价是如何考虑的？

① 根据会员价设置入门最低门槛。会员价相当于原价的5.5-7折，而正善的商品最低价格都在200元左右，所以意味着会员至少可享受减60元的优惠，最低门槛的双日卡价格定为28元，优惠的价格远超双日卡的费用，用户自然就会选择购买付费会员卡。

② 区分包邮权益。正善牛肉是顺丰全冷链运输，平均运费在50元左右，但双日卡不包邮，客户需要自己承担运费。这时168元的月卡成为最好的选择，因为会员价享受的优惠加上邮费，最低也有110元了，购买两次，享受的优惠就可以抵消月卡的费用。

③ 利用“物尽其用”消费心理。想在一次购物当中将168元的卡费省回，至少要买6斤牛肉，一个3口之家短期内较难消耗这些牛肉。但大部分人都有“既然买了卡，那就要物尽其用”的心理，这促使客户进店复购或发动好友一起买，让用户自发的引流与复购。

正是这样的定价为正善每月带来超过80%的复购和持续不断的粉丝增长，客单价也从17年的300元提高到现在的1035元。

问题

错误内容：

1
2
3
4
5
6
7
8
9
10

brew install nginx
==> Downloading https://mirrors.ustc.edu.cn/homebrew-bottles/bottles/openssl%401.1-1.1.1j.big_sur.bottle.tar.gz
#=#=#                                                                         
curl: (22) The requested URL returned error: 404 
Trying a mirror...
==> Downloading https://homebrew.bintray.com/bottles/openssl%401.1-1.1.1j.big_sur.bottle.tar.gz
#=#=-#  #                                                                     
curl: (22) The requested URL returned error: 403 Forbidden
Error: Failed to download resource "openssl@1.1"
Download failed: https://homebrew.bintray.com/bottles/openssl%401.1-1.1.1j.big_sur.bottle.tar.gz

原因&解决

之前brew使用的教育源。教育源无法找到openssl资源导致无法安装nginx

更换至阿里云的源，问题解决。

1
2
3
4
5
6
7
8
9
10

# 替换brew.git
cd "$(brew --repo)"
git remote set-url origin https://mirrors.aliyun.com/homebrew/brew.git

# 替换homebrew-core.git
cd "$(brew --repo)/Library/Taps/homebrew/homebrew-core"
git remote set-url origin https://mirrors.aliyun.com/homebrew/homebrew-core.git

# 刷新源
brew update

Nginx 常用指令

nginx -V 查看版本以及配置文件地址

nginx -v 查看版本

nginx -c filename 指定配置文件

nginx -h 帮助

问题

应用在docker环境下使用new font()黑体、宋体字体显示方框乱码。

图片上的汉字是用new font画出来的，使用的黑体字体。

解决

可以在Windows系统目录 C:\Windows\Fonts 复制需要的字体到项目里, 然后在Dockerfile 引入.

找到所需要的字体文件，如黑体为：simhei.ttf。复制到dockerfile所在目录下。

dockerfile加入：

1	COPY fonts/simhei.ttf /usr/share/fonts/

重新构建镜像。问题解决

问题

nacos服务器所在IP进行了更换，dubbo consumers启动依然请求旧的providers服务地址。

• 首先排除dubbo缓存，找到文件夹：$用户名$/.dubbo 删除文件夹下文件。问题依然重现。

• 删除nacos注册缓存，找到文件夹： $用户名$/nacos 删除文件夹下所有文件，问题解决。

思考

dubbo缓存

• 根据官方图，dubbo调用者需要通过注册中心（例如：ZK、nacos）注册信息，获取提供者，但是如果频繁往ZK获取信息，肯定会存在单点故障问题，所以dubbo提供了将提供者信息缓存在本地的方法。
• Dubbo在订阅注册中心的回调处理逻辑当中会保存服务提供者信息到本地缓存文件当中（同步/异步两种方式），以url纬度进行全量保存。
• Dubbo在服务引用过程中会创建registry对象并加载本地缓存文件，会优先订阅注册中心，订阅注册中心失败后会访问本地缓存文件内容获取服务提供信息。

nacos缓存

查看源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public void init() {
    executorService.scheduleWithFixedDelay(new SwitchRefresher(), 0L, 5000L, TimeUnit.MILLISECONDS);
    executorService.scheduleWithFixedDelay(new DiskFileWriter(), 30, DAY_PERIOD_MINUTES, TimeUnit.MINUTES);
    // backup file on startup if failover directory is empty.
    executorService.schedule(new Runnable() {
        @Override
        public void run() {
            try {
                File cacheDir = new File(failoverDir);

                if (!cacheDir.exists() && !cacheDir.mkdirs()) {
                    throw new IllegalStateException("failed to create cache dir: " + failoverDir);
                }

                File[] files = cacheDir.listFiles();
                if (files == null || files.length <= 0) {
                    new DiskFileWriter().run();
                }
            } catch (Throwable e) {
                LogUtils.LOG.error("NA", "failed to backup file on startup.", e);
            }

        }
    }, 10000L, TimeUnit.MILLISECONDS);}

创建定时器，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

class SwitchRefresher implements Runnable {
    long lastModifiedMillis = 0L;
    @Override
    public void run() {
        try {
            File switchFile = new File(failoverDir + UtilAndComs.FAILOVER_SWITCH);
            if (!switchFile.exists()) {
                switchParams.put("failover-mode", "false");
                LogUtils.LOG.debug("failover switch is not found, " + switchFile.getName());
                return;
            }
            long modified = switchFile.lastModified();
            if (lastModifiedMillis < modified) {
                lastModifiedMillis = modified;
                String failover = ConcurrentDiskUtil.getFileContent(failoverDir + UtilAndComs.FAILOVER_SWITCH, Charset.defaultCharset().toString());
                if (!StringUtils.isEmpty(failover)) {
                    List<String> lines = Arrays.asList(failover.split(DiskCache.getLineSeperator()));
                    for (String line : lines) {
                        String line1 = line.trim();
                        if ("1".equals(line1)) {
                            switchParams.put("failover-mode", "true");
                            LogUtils.LOG.info("failover-mode is on");
                            new FailoverFileReader().run();
                        } else if ("0".equals(line1)) {
                            switchParams.put("failover-mode", "false");
                            LogUtils.LOG.info("failover-mode is off");
                        }
                    }
                } else {
                    switchParams.put("failover-mode", "false");
                }
            }
        } catch (Throwable e) {
            LogUtils.LOG.error("NA", "failed to read failover switch.", e);
        }
    }}

首先判定下容灾开关是否有，容灾开关是一个磁盘文件的形式存在，通过容灾开关文件名字，判定容灾开关是否打开，1表示打开，0为关闭，读取到容灾开关后，将值更新到内存中，后续解析地址列表时，首先会判定一下容灾开关是否打开，如果打开了，就读缓存的数据，否则从服务端获取最新数据。

猜测是容灾开关打开状态，所以一直取的缓存的数据。

获取 redis 镜像 docker pull redis

查看本地镜像 docker images

从官网获取 redis.conf 配置文件

1. 修改默认配置文件

• bind 127.0.0.1 #注释掉这部分，这是限制redis只能本地访问
• protected-mode no #默认yes，开启保护模式，限制为本地访问
• daemonize no#默认no，改为yes意为以守护进程方式启动，可后台运行，除非kill进程（可选），改为yes会使配置文件方式启动redis失败
• dir ./ #输入本地redis数据库存放文件夹（可选）
• appendonly yes #redis持久化（可选）

2. docker 启动 redis 命令

   docker run -p 6379:6379 --name redis -v /usr/local/docker/redis.conf:/etc/redis/redis.conf -v /usr/local/docker/data:/data -d redis redis-server /etc/redis/redis.conf --appendonly yes

3. 不挂载配置文件:

   docker run --name redis -p 6379:6379 -d --restart=always redis redis-server --appendonly yes --requirepass "这是密码"

4. 命令解释说明：

• -p 6379:6379 端口映射：前表示主机部分，：后表示容器部分。
• –name myredis 指定该容器名称，查看和进行操作都比较方便。
• -v 挂载目录，规则与端口映射相同。
• -d redis 表示后台启动redis
• redis-server /etc/redis/redis.conf 以配置文件启动redis，加载容器内的conf文件，最终找到的是挂载的目录/usr/local/docker/redis.conf
• appendonly yes 开启redis 持久化

运行成功

1. 使用docker ps 查看redis已经运行了

   

2. 使用 docker exec -it redis /bin/bash进入redis

3. 使用 redis-cli 可以测试连接。

4. 这样是默认不设置密码的，spring连接方式配置为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# REDIS配置
 
# Redis数据库索引（默认为0）
spring.redis.database=0
 
# Redis服务器IP地址
spring.redis.host=127.0.0.1
 
# Redis服务器连接端口
spring.redis.port=6379
 
# Redis服务器连接密码（默认为空，可不配置此项）
# spring.redis.password=xxx
 
# 连接池最大连接数（使用负值表示没有限制）
spring.redis.lettuce.pool.max-active=500
 
# 连接池最大阻塞等待时间（使用负值表示没有限制）
spring.redis.lettuce.pool.max-wait=-1
 
# 连接池中的最大空闲连接
spring.redis.lettuce.pool.max-idle=8
 
# 连接池中的最小空闲连接
spring.redis.lettuce.pool.min-idle=0
 
# 连接超时时间（毫秒）
spring.redis.timeout=0

起因

小程序上线之后发现一个奇怪的现象，页面向下滑动，点击事件会延迟几秒。滑动的越多，延迟就越久，点击会出现几秒才会能打开新的页面。前端同学没有排查出原因，更换了几种跳转方式问题依旧。

排查

review了一下代码，发现如下代码。能看出问题吗？

1
2
3
4
5
6
7
8
9
10
11
12
13

onPageScroll(e) {
  if (this.data.offsetTop >= e.scrollTop && this.data.isFixed) {
    this.getHeaderHeight();
    this.setData({
      isFixed: false
    })
  } else {
    this.getHeaderHeight();
    this.setData({
      isFixed: true
    })
  }
}

页面滚动事件中会不断的执行 setData事件，导致事件阻塞。

更改成如下代码解决：

1
2
3
4
5
6
7
8
9
10
11
12
13

onPageScroll(e) {
  if (this.data.offsetTop >= e.scrollTop && this.data.isFixed) {
    this.getHeaderHeight();
    this.setData({
      isFixed: false
    })
  } else if(e.scrollTop > this.data.offsetTop && !this.data.isFixed){
    this.getHeaderHeight();
    this.setData({
      isFixed: true
    })
  }
}

根源

阿里云所有的特惠活动都是针对新用户，一台1W+的服务器，新用户可以拿到3千多3年，老用户则只有一点点优惠。无奈为了省钱只能拿新手机，新身份证，新公司资质申请账号进行购买，所以导致现在手上的阿里云账号有十来个了。所以务必要解决这十几个账号里的ECS资源能够内网互通。

同地域内网互通方案

云企业网（Cloud Enterprise Network）是承载在阿里云提供的高性能、低延迟的私有全球网络上的一张高可用网络。

云企业网可帮助您在不同地域VPC间，VPC与本地数据中心间搭建私网通信通道，通过自动路由分发及学习，提高网络的快速收敛和跨网络通信的质量和安全性，实现全网资源的互通，帮助您打造一张具有企业级规模和通信能力的互联网络。

1. 首先拿一个主账号创建云企网实例

   https://cen.console.aliyun.com/cen/list

2. 其他需要加入云企网的账号，进入专有网络VPC控制台，云企网跨账号授权给刚刚创建的主账号。

   

3. 再回到主账号上的云企网，进入详情，点击加载网络实例，填写其他账号的信息。

   

4. 这样就完成了同地域跨账号的内网互通。如碰到内网还是不通，可能是内网IP段冲突，更改VPC交换机IP段。不知道怎么操作提交宫工单给阿里云。

跨地域互通方案

这个就要花钱了。购买跨地域宽带包，然后按照上述步骤加载网络实例。

某天，晴，准时下班与朋友小聚，酒足饭饱后正商量着第二场活动，这时手机短信响起，随手拿起一看。卧槽，提示服务器蠕虫病毒。遂与友人say sorry。回家打开电脑开始杀毒并排查原因。

首先打开阿里云看下日志。这里还是要点赞一下阿里云的云盾，服务器防护与预警属实做的很牛逼。日志提示服务器被植入挖矿程序，并且告知所在进程

查看到是在容器内植入，好在没有植入我的宿主机。当前主机挂载了好几个容器服务。并且宿主机有做端口限制，应该是跑不出去。

逐步排查原因：

执行top可看到挖矿程序疯狂占用CPU。

ps查看进程运行目录，发现tmp中不存在这个文件，猜想可能是docker容器中的进程。

执行 docker stats 查看容器运行情况。能够发现cpu占用高的容器。

执行 docker top 容器id 查看容器进程详细信息

为什么会被植入？

• 网上说的redis漏洞。

  该镜像没有集成redis。PASS

• 镜像本身是否存在病毒？

  很多镜像可能会集成第三方的插件，或者jar包。那么排查镜像源问题，可使用命令 docker inspect <镜像id> 查看镜像元数据进行排查。我镜像都是自己打包上传，并且本地重新下载镜像并未发现任何异常。大概率PASS

• 远程执行漏洞?

  那就很有可能是存在这个问题了。该docker容器开放了9999(用于xxl-job分布式事务)，8085用于spring-boot服务(大概率可以排除)。那就应该是XXL-JOB的锅了。搜索得知，XXL-JOB远程执行漏洞导致kdevtmpfsi挖矿病毒：

  https://help.aliyun.com/noticelist/articleid/1060736995.html?spm=5176.2020520154.sas.52.e96d1e430g70fo

最终解决

1、9999端口加上IP限制，只允许xxljob-admin源服务器ip地址调用。

2、xxl-job增加授权验证，配置 xxl.job.accessToken 防止未授权访问漏洞。

如何不使用Nexus搭建属于自己团队的一个maven或者Gradle私有仓。这里推荐使用阿里云新出的产品：云效。云效有个产品叫做制品库，我们可以利用制品库快速搭建自己的maven私有仓库。

云效：制品库

注册阿里云云效平台账号：https://devops.aliyun.com/。进入制品库，发现已经拥有发布以及快照两个仓。点击进去会有文档告知如何配置maven环境，推荐方式1直接覆盖settings文件即可

Idea设置使用自定义settings文件

如何单模块打包

首先弄懂maven的snapshot快照仓库和release发布仓库，所以打包也分为release包跟snapshot快照包。snapshot快照仓库用于保存开发过程中的不稳定版本，release正式仓库则是用来保存稳定的发行版本。
定义一个组件/模块为快照版本，只需要在pom文件中在该模块的版本号后加上-SNAPSHOT即可(注意这里必须是大写)，如下：

1
2
3
4

<groupId>com.rednet</groupId>
<artifactId>m1</artifactId>
<version>0.1-SNAPSHOT</version>
<packaging>jar</packaging>

如果是快照版本，那么在mvn deploy时会自动发布到快照版本库中，而使用快照版本的模块，在不更改版本号的情况下，直接编译打包时，maven会自动从镜像服务器上下载最新的快照版本。但是release不改版本号情况会出现如下错误

Failed to transfer file https://packages.aliyun.com/maven/repository/2019159-release-3dosVm/com/rednet/framework/spring-boot-starter-sms/1.0.2/spring-boot-starter-sms-1.0.2.jar with status code 409

IDEA无法更新最新的snapshot快照包，如何解决？IDEA->设置-》maven-》勾选aways update snapshots。

在模块中直接运行以下代码即可推送jar包到自己的阿里云私有仓
`
$ mvn clean deploy -DskipTests

`
也可以在IDEA中点击maven-》Lifecycle-》deploy进行发布。