早前搭过一个wiki (可点击wiki.dashen.tech 查看),用于"团队协作与知识分享".把游客账号给一位前同事,其告知登录出错.

用我记录的账号密码登录,同样报错; 打开数据库一看,疑惑全消.

To recover your lost Database and avoid leaking it: Send us 0.05 Bitcoin (BTC) to our Bitcoin address 3F4hqV3BRYf9JkPasL8yUPSQ5ks3FF3tS1 and contact us by Email with your Server IP or Domain name and a Proof of Payment. Your Database is downloaded and backed up on our servers. Backups that we have right now: mm_wiki, shuang. If we dont receive your payment in the next 10 Days, we will make your database public or use them otherwise.

(按照今日比特币价格,0.05比特币折合人民币4 248.05元..)

大多时候不使用该服务器上安装的mysql,因而账号和端口皆为默认,密码较简单且常见,为在任何地方navicat也可连接,去掉了ip限制...对方写一个脚本,扫描各段ip地址,用常见的几个账号和密码去"撞库",几千几万个里面,总有一两个能得手.

被窃取备份而后删除的两个库,一个是来搭建该wiki系统,另一个是用来亲测mysql主从同步,详见此篇,价值都不大

实践告诉我们，不要用默认账号，不要用简单密码，要做ip限制。…

• 登录服务器,登录到mysql:

mysql -u root -p

• 修改密码:

尝试使用如下语句来修改

set password for 用户名@yourhost = password('新密码');

结果报错;查询得知是最新版本更改了语法,需用

alter user 'root'@'localhost' identified by 'yourpassword';

成功~

但在navicat里,原连接依然有效,而输入最新的密码,反倒是失败

打码部分为本机ip

在服务器执行

-- 查询所有用户

select user from mysql.user;

再执行

select host,user,authentication_string from mysql.user;

user及其后的host组合在一起,才构成一个唯一标识;故而在user表中,可以存在同名的root

使用

alter user 'root'@'%' identified by 'xxxxxx';

注意主机此处应为%

再使用

select host,user,authentication_string from mysql.user;

发现 "root@%" 对应的authentication_string已发生改变;

在navicat中旧密码已失效,需用最新密码才可登录

参考:

mysql 5.7 修改用户密码

关于修改账号,可参考此

这不是第一次遭遇"比特币勒索",在四月份,收到了这么一封邮件:

后来证明这是唬人的假消息,但还是让我学小扎,把Mac的摄像头覆盖了起来..

一、一个难查的生产问题

一天，小王发现生产环境上偶发性地出现某接口耗时过高，但在测试环境又无法复现，小王一筹莫展😔。小王“幻想”到：如果有个工具能记录生产上各个函数的耗时该多好，这样一看不就知道时间花在哪了？
这不是幻想，Arthas 已经帮我们解决了这个问题。在介绍它之前，我们先了解下相关背景。

二、动态追踪

现在互联网和大家生活的各个方面都息息相关。相应地，互联网应用的用户规模也变得越来越大。江湖大了，什么风浪都有。开发者们不断被各种诡异问题打扰，接口耗时过大、CPU 占用过高、内存溢出、只有生产环境会报错......
这些问题出现的概率可能是千分之一、乃至万分之一。如果我们能不修改代码、不修改配置、不重启服务，就能看到程序内部在执行什么，这该多好，再大的问题心里也有底了。
动态追踪技术出现了，它诞生于21 世纪初。Sun Microsystems 公司的工程师在解决一个复杂问题时被繁琐的排查过程所困扰，痛定思痛，他们创造了 DTrace 动态跟踪框架。DTrace 奠定了动态追踪的基础，Bryan Cantrill, Mike Shapiro, and Adam Leventhal 三位作者也多次获得行业荣誉。
动态追踪技术出现的时间早，但 Java 语言相关的调试工具链一直不太完善。直到进入移动互联网时代，Java 的发展才进入了快车道。2018 年，Alibaba 开源 Arthas，Java 的动态追踪才真正好用起来。
动态追踪可以看作是构建了一个运行时“只读数据库”，这个数据库内部保存了实时变化的进程运行信息，我们通过调用这个“数据库”开放的接口，就能看到进程内部发生了什么。
经验丰富的读者可能会有疑问，现在微服务都用上了 Skywalking 这样的分布式链路追踪技术，通过它也能分阶段地看到各个部分的执行情况，为什么还需要 Arthas？
Arthas 有两大特点：

1. 低侵入；不需要程序中进行额外配置，更不需要手动埋点。
2. 功能强大；Arthas 提供了四十多种命令：从查看线程调用链，到查看输入、输出，到反编译代码等，应有尽有。

对于排查接口耗时长这样的情况，Skywalking 可以和 Arthas 配合起来，先用 Skywalking 定位出异常微服务，再用 Arthas 分析单个进程的情况，找到根因。

三、Arthas常用场景

相信你对动态追踪有了基本的了解，Arthas 可以理解为动态追踪在 Java 领域落地的具体工具。下面以场景助学，大家可以参考这些方案，因事制宜来解决自己的问题。

Arthas 的安装和基础使用见官方文档：Introduction | arthas。

3.1.接口慢/吞吐量低

在文章开头，小王就遇到了这个问题。现在小王依靠老道的排查经验确定了 MathGame 服务肯定有问题，但具体的点却找不到。小王仔细学习了这篇文章，决定用 Arthas 分以下三步来排查：

1. profile 明确整体的耗时情况

   profile 命令支持为应用生成火焰图，在 Arthas 终端输入以下命令：

   # 开始对应用中当前执行的活动采样 30 秒，采样结束后默认会生成 HTML 文件
   
   [arthas@5555]$ profiler start -d 30
   
   

   打开 HTML 文件能看到这样的结构：

   
   火焰图

   MathGame 类下的 run 方法占用了大部分的执行时间，接下来我们看看 run 方法内部的耗时情况。

2. trace 详细查看单个调用的内部耗时

   [arthas@5555]$ trace --skipJDKMethod false demo.MathGame run
   
   

   PrintStream 类的 print 方法占据了 87% 的时间，这是 JDK 自带的类，这说明我们程序本身并无耗时问题，但 MathGame 类的 primeFactors 方法抛出了异常，我们可以看看具体的异常，再思考怎么优化。

   
   run方法的trace流

   另外，trace 可以选择性地进行调用拦截，比如设置只拦截大于 20ms 的调用：

   [arthas@5555]$ trace demo.MathGame run '#cost > 20'
   
   

3. watch 查看真实的调用数据

   拦截 primeFactors 方法抛出的异常：

   [arthas@5555]$ watch demo.MathGame primeFactors -e "throwExp"
   
   

   
   拦截异常

小王从大到小、逐步分析，找出了问题的原因是 primeFactors 抛出了异常，修正参数后，程序恢复了正常。

3.2.CPU 占用过高

CPU 是程序运行的核心计算资源，一旦出现 CPU 占用过高，必定对大部分用户的访问耗时产生影响。针对这类问题，要定位出有问题的线程，并获取该线程当前执行的代码位置。
使用 top + jstack 命令可以定位这类问题（见参考资料三），Arthas 也提供了更便捷的一体化工具：

1. 定位目标线程

   # 调用线程看板，并刷新数据三次
   
   [arthas@5555]$ dashboard -n 3
   
   

   
   示例程序的CPU占用不算高

   DashBoard 刷新三次后，在最新状态中发现示例程序里自己的线程 “main” 占用不算高。说明程序运行正常。如果是要排错，这里就要找出 CPU 占用最高的用户线程的 ID。

2. 查看目标线程执行的代码位置

   # “1” 是上一步定位到的 main 的线程ID
   
   [arthas@5555]$ thread 1
   
   

   

   线程正在“睡觉”，没什么大问题。

3.3 生产环境的效果和测试不一样

有些时候你发现：测试环境正常，但生产就报错了。这类问题主要靠做好上线流程的管控，但也有可能是打包的依赖库出现冲突，造成程序行为不一致。接下来，我们看看怎么用 Arthas 反编译代码，以及怎么对比依赖库的版本。

1. 反编译代码

   # demo.MathGame 是目标类的全限定名
   
   [arthas@5555]$ jad demo.MathGame
   
   

2. 查看目标类所属的依赖包

   # demo.MathGame 是目标类的全限定名
   
   [arthas@5555]$ sc -d demo.MathGame
   
   

   
   目标类所属的包

   如果这里是依赖包，code-source 还可以显示所属包的版本。这样就可以对比本地的代码，从而在打包时设置正确的依赖版本。

3.4 内存溢出

生产问题中内存溢出也有不小的比例。内存溢出的关键是找出高内存占用的对象。命令行操作会比较麻烦，建议转储 Heap Dump 等文件后，通过 Eclipse Memory Analyzer(MAT) 等工具进行分析。

四、运行 Arthas 报错

在有些运行环境下，Arthas 会出现报错。对于以下两种情况，读者可参照文档解决：

• 不兼容 Skywalking
  Compatible-with-other-javaagent-bytecode-processing
• Alpine 镜像的容器无法生成火焰图
  Alpine容器镜像中生成火焰图错误的其它解决方案

五、参考资料

1. 动态追踪技术漫谈 - OpenResty 官方博客
2. DTrace - Wikipedia --- DTrace - 维基百科，自由的百科全书
3. 用JStack和Top分析Java进程CPU占用率_java top threads-CSDN博客
4. Introduction | arthas --- 简介 |阿尔萨斯 (aliyun.com)
5. 如何读懂火焰图？ - 阮一峰的网络日志 (ruanyifeng.com)

作者：立子
来源：juejin.cn/post/7308230350374256666

大家好，我是小富～

简介

项目开发中经常会遇到多数据源同时使用的场景，比如冷热数据的查询等情况，我们可以使用类似现成的工具包来解决问题，但在多数据源的使用中通常伴随着定制化的业务，所以一般的公司还是会自行实现多数据源切换的功能，接下来一起使用实现自定义注解的形式来实现一下。

基础配置

yml配置

pom.xml文件引入必要的Jar

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"

         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <parent>

        <groupId>org.springframework.boot</groupId>

        <artifactId>spring-boot-starter-parent</artifactId>

        <version>2.7.6</version>

    </parent>

    <groupId>com.dynamic</groupId>

    <artifactId>springboot-dynamic-datasource</artifactId>

    <version>0.0.1-SNAPSHOT</version>

    <properties>

        <maven.compiler.source>8</maven.compiler.source>

        <maven.compiler.target>8</maven.compiler.target>

        <mybatis.plus.version>3.5.3.1</mybatis.plus.version>

        <mysql.connector.version>8.0.32</mysql.connector.version>

        <druid.version>1.2.6</druid.version>

    </properties>



    <dependencies>

        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter</artifactId>

        </dependency>

        <!-- springboot核心包 -->

        <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-web</artifactId>

        </dependency>

        <!-- mysql驱动包 -->

        <dependency>

            <groupId>com.mysql</groupId>

            <artifactId>mysql-connector-j</artifactId>

            <version>${mysql.connector.version}</version>

        </dependency>

        <!-- lombok工具包 -->

        <dependency>

            <groupId>org.projectlombok</groupId>

            <artifactId>lombok</artifactId>

            <optional>true</optional>

        </dependency>

        <!-- MyBatis Plus -->

        <dependency>

            <groupId>com.baomidou</groupId>

            <artifactId>mybatis-plus-boot-starter</artifactId>

            <version>${mybatis.plus.version}</version>

        </dependency>

        <!-- druid -->

        <dependency>

            <groupId>com.alibaba</groupId>

            <artifactId>druid-spring-boot-starter</artifactId>

            <version>${druid.version}</version>

        </dependency>

        <dependency>

            <groupId>org.apache.commons</groupId>

            <artifactId>commons-lang3</artifactId>

            <version>3.7</version>

        </dependency>

        <dependency>

            <groupId>org.aspectj</groupId>

            <artifactId>aspectjweaver</artifactId>

        </dependency>

    </dependencies>



    <build>

        <plugins>

            <plugin>

                <groupId>org.springframework.boot</groupId>

                <artifactId>spring-boot-maven-plugin</artifactId>

            </plugin>

        </plugins>

    </build>

</project>

管理数据源

我们应用ThreadLocal来管理数据源信息，通过其中内容的get，set，remove方法来获取、设置、删除当前线程对应的数据源。

/**

 * ThreadLocal存放数据源变量

 *

 * @author 公众号：程序员小富

 * @date 2023/11/27 11:02

 */

public class DataSourceContextHolder {



    private static final ThreadLocal<String> DATASOURCE_HOLDER = new ThreadLocal<>();



    /**

     * 获取当前线程的数据源

     *

     * @return 数据源名称

     */

    public static String getDataSource() {

        return DATASOURCE_HOLDER.get();

    }



    /**

     * 设置数据源

     *

     * @param dataSourceName 数据源名称

     */

    public static void setDataSource(String dataSourceName) {

        DATASOURCE_HOLDER.set(dataSourceName);

    }



    /**

     * 删除当前数据源

     */

    public static void removeDataSource() {

        DATASOURCE_HOLDER.remove();

    }

}

重置数据源

创建 DynamicDataSource 类并继承 AbstractRoutingDataSource，这样我们就可以重置当前的数据库路由，实现切换成想要执行的目标数据库。

import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;

import javax.sql.DataSource;

import java.util.Map;



/**

 * 重置当前的数据库路由，实现切换成想要执行的目标数据库

 *

 * @author 公众号：程序员小富

 * @date 2023/11/27 11:02

 */

public class DynamicDataSource extends AbstractRoutingDataSource {



    public DynamicDataSource(DataSource defaultDataSource, Map<Object, Object> targetDataSources) {

        super.setDefaultTargetDataSource(defaultDataSource);

        super.setTargetDataSources(targetDataSources);

    }



    /**

     * 这一步是关键，获取注册的数据源信息

     * @return

     */

    @Override

    protected Object determineCurrentLookupKey() {

        return DataSourceContextHolder.getDataSource();

    }

}

配置数据库

在 application.yml 中配置数据库信息，使用dynamic_datasource_1、dynamic_datasource_2两个数据库

spring:

  datasource:

    type: com.alibaba.druid.pool.DruidDataSource

    druid:

      master:

        url: jdbc:mysql://127.0.0.1:3306/dynamic_datasource_1?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true

        username: root

        password: 12345

        driver-class-name: com.mysql.cj.jdbc.Driver

      slave:

        url: jdbc:mysql://127.0.0.1:3306/dynamic_datasource_2?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true

        username: root

        password: 12345

        driver-class-name: com.mysql.cj.jdbc.Driver

再将多个数据源注册到DataSource.

import com.alibaba.druid.spring.boot.autoconfigure.DruidDataSourceBuilder;

import org.springframework.boot.context.properties.ConfigurationProperties;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import org.springframework.context.annotation.Primary;

import javax.sql.DataSource;

import java.util.HashMap;

import java.util.Map;



/**

 * 注册多个数据源

 *

 * @author 公众号：程序员小富

 * @date 2023/11/27 11:02

 */

@Configuration

public class DateSourceConfig {



    @Bean

    @ConfigurationProperties("spring.datasource.druid.master")

    public DataSource dynamicDatasourceMaster() {

        return DruidDataSourceBuilder.create().build();

    }



    @Bean

    @ConfigurationProperties("spring.datasource.druid.slave")

    public DataSource dynamicDatasourceSlave() {

        return DruidDataSourceBuilder.create().build();

    }



    @Bean(name = "dynamicDataSource")

    @Primary

    public DynamicDataSource createDynamicDataSource() {

        Map<Object, Object> dataSourceMap = new HashMap<>();

        // 设置默认的数据源为Master

        DataSource defaultDataSource = dynamicDatasourceMaster();

        dataSourceMap.put("master", defaultDataSource);

        dataSourceMap.put("slave", dynamicDatasourceSlave());

        return new DynamicDataSource(defaultDataSource, dataSourceMap);

    }

}

启动类配置

在启动类的@SpringBootApplication注解中排除DataSourceAutoConfiguration，否则会报错。

@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)

到这多数据源的基础配置就结束了，接下来测试一下

测试切换

准备SQL

创建两个库dynamic_datasource_1、dynamic_datasource_2，库中均创建同一张表 t_dynamic_datasource_data。

CREATE TABLE `t_dynamic_datasource_data` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT,

  `source_name` varchar(255) DEFAULT NULL,

  PRIMARY KEY (`id`)

);

dynamic_datasource_1.t_dynamic_datasource_data表中插入

insert int0 t_dynamic_datasource_data (source_name) value ('dynamic_datasource_master');

dynamic_datasource_2.t_dynamic_datasource_data表中插入

insert int0 t_dynamic_datasource_data (source_name) value ('dynamic_datasource_slave');

手动切换数据源

这里我准备了一个接口来验证，传入的 datasourceName 参数值就是刚刚注册的数据源的key。

/**

 * 动态数据源切换

 *

 * @author 公众号：程序员小富

 * @date 2023/11/27 11:02

 */

@RestController

public class DynamicSwitchController {



    @Resource

    private DynamicDatasourceDataMapper dynamicDatasourceDataMapper;



    @GetMapping("/switchDataSource/{datasourceName}")

    public String switchDataSource(@PathVariable("datasourceName") String datasourceName) {

        DataSourceContextHolder.setDataSource(datasourceName);

        DynamicDatasourceData dynamicDatasourceData = dynamicDatasourceDataMapper.selectOne(null);

        DataSourceContextHolder.removeDataSource();

        return dynamicDatasourceData.getSourceName();

    }

}

传入参数master时：127.0.0.1:9004/switchDataSource/master

传入参数slave时：127.0.0.1:9004/switchDataSource/slave

通过执行结果，我们看到传递不同的数据源名称，已经实现了查询对应的数据库数据。

注解切换数据源

上边已经成功实现了手动切换数据源，但这种方式顶多算是半自动，下边我们来使用注解方式实现动态切换。

定义注解

我们先定一个名为DS的注解，作用域为METHOD方法上，由于@DS中设置的默认值是：master，因此在调用主数据源时，可以不用进行传值。

/**

 * 定于数据源切换注解

 *

 * @author 公众号：程序员小富

 * @date 2023/11/27 11:02

 */

@Target({ElementType.METHOD, ElementType.TYPE})

@Retention(RetentionPolicy.RUNTIME)

@Documented

@Inherited

public @interface DS {

    // 默认数据源master

    String value() default "master";

}

实现AOP

定义了@DS注解后，紧接着实现注解的AOP逻辑，拿到注解传递值，然后设置当前线程的数据源

import com.dynamic.config.DataSourceContextHolder;

import lombok.extern.slf4j.Slf4j;

import org.aspectj.lang.ProceedingJoinPoint;

import org.aspectj.lang.annotation.Around;

import org.aspectj.lang.annotation.Aspect;

import org.aspectj.lang.annotation.Pointcut;

import org.aspectj.lang.reflect.MethodSignature;

import org.springframework.stereotype.Component;

import java.lang.reflect.Method;

import java.util.Objects;



/**

 * 实现@DS注解的AOP切面

 *

 * @author 公众号：程序员小富

 * @date 2023/11/27 11:02

 */

@Aspect

@Component

@Slf4j

public class DSAspect {



    @Pointcut("@annotation(com.dynamic.aspect.DS)")

    public void dynamicDataSource() {

    }



    @Around("dynamicDataSource()")

    public Object datasourceAround(ProceedingJoinPoint point) throws Throwable {

        MethodSignature signature = (MethodSignature) point.getSignature();

        Method method = signature.getMethod();

        DS ds = method.getAnnotation(DS.class);

        if (Objects.nonNull(ds)) {

            DataSourceContextHolder.setDataSource(ds.value());

        }

        try {

            return point.proceed();

        } finally {

            DataSourceContextHolder.removeDataSource();

        }

    }

}

测试注解

再添加两个接口测试，使用@DS注解标注，使用不同的数据源名称，内部执行相同的查询条件，看看结果如何？

@DS(value = "master")

@GetMapping("/dbMaster")

public String dbMaster() {

    DynamicDatasourceData dynamicDatasourceData = dynamicDatasourceDataMapper.selectOne(null);

    return dynamicDatasourceData.getSourceName();

}

@DS(value = "slave")

@GetMapping("/dbSlave")

public String dbSlave() {

    DynamicDatasourceData dynamicDatasourceData = dynamicDatasourceDataMapper.selectOne(null);

    return dynamicDatasourceData.getSourceName();

}

通过执行结果，看到通过应用@DS注解也成功的进行了数据源的切换。

事务管理

在动态切换数据源的时候有一个问题是要考虑的，那就是事务管理是否还会生效呢？

我们做个测试，新增一个接口分别插入两条记录，其中在插入第二条数据时将值设置超过了字段长度限制，会产生Data too long for column异常。

    /**

     * 验证一下事物控制

     */

//    @Transactional(rollbackFor = Exception.class)

    @DS(value = "slave")

    @GetMapping("/dbTestTransactional")

    public void dbTestTransactional() {



        DynamicDatasourceData datasourceData = new DynamicDatasourceData();

        datasourceData.setSourceName("test");

        dynamicDatasourceDataMapper.insert(datasourceData);



        DynamicDatasourceData datasourceData1 = new DynamicDatasourceData();

        datasourceData1.setSourceName("testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest");

        dynamicDatasourceDataMapper.insert(datasourceData1);

    }

经过测试发现执行结果如下，即便实现动态切换数据源，本地事务依然可以生效。

• 不加上@Transactional注解第一条记录可以插入，第二条插入失败


• 加上@Transactional注解两条记录都不会插入成功

本文案例地址：github.com/chengxy-nds…

在Java 8引入的Lambda表达式和函数式接口之后，双冒号运算符(::)成为了一项重要的功能。它可以将方法或构造函数作为参数传递，简化了编码和提升了代码的可读性。本文将介绍Java中的双冒号运算符及其常见应用场景。

双冒号运算符(::)的语法

双冒号运算符的语法是类名/对象名::方法名。具体来说，它有三种不同的使用方式：

静态方法引用

首先，我们来看一下如何使用双冒号运算符引用静态方法。假设有一个Utils类，其中有一个静态方法processData：

public class Utils {

    public static void processData(String data) {

        System.out.println("Processing data: " + data);

    }

}

我们可以使用双冒号运算符将该方法作为参数传递给其他方法：

List<String> dataList = Arrays.asList("data1", "data2", "data3");

dataList.forEach(Utils::processData);

上述代码等效于使用Lambda表达式的方式：

dataList.forEach(data -> Utils.processData(data));

通过使用双冒号运算符，我们避免了重复写Lambda表达式，使代码更加简洁和易读。

实例方法引用

双冒号运算符还可以用于引用实例方法。假设我们有一个User类，包含了一个实例方法getUserInfo：

public class User {

    public void getUserInfo() {

        System.out.println("Getting user info...");

    }

}

我们可以通过双冒号运算符引用该实例方法：

User user = new User();

Runnable getInfo = user::getUserInfo;

getInfo.run();

上述代码中，我们创建了一个Runnable对象，并将user::getUserInfo作为方法引用赋值给它。然后，通过调用run方法来执行该方法引用。

构造函数引用

在Java 8之前，要使用构造函数创建对象，需要通过写出完整的类名以及参数列表来调用构造函数。而使用双冒号运算符，我们可以将构造函数作为方法引用，实现更加简洁的对象创建方式。

假设有一个Person类，拥有一个带有name参数的构造函数：

public class Person {

    private String name;



    public Person(String name) {

        this.name = name;

    }



    public String getName() {

        return name;

    }

}

我们可以使用双冒号运算符引用该构造函数并创建对象：

Supplier<Person> personSupplier = Person::new;

Person person = personSupplier.get();

person.getName(); // 调用实例方法

上述代码中，我们使用Person::new将构造函数引用赋值给Supplier接口，然后通过get方法创建了Person对象。

总结

本文介绍了Java中双冒号运算符(::)的语法及其常见的应用场景。通过双冒号运算符，我们可以更方便地引用静态方法、实例方法和构造函数，使得代码更加简洁和可读。双冒号运算符是Java 8引入的重要特性，对于函数式编程和Lambda表达式的使用起到了积极的推动作用。

希望本文能够帮助您理解和应用双冒号运算符，提高Java开发的效率和代码质量。如有任何问题或疑惑，欢迎提问！

背景

相信大家都有点外卖的时候去按照附近公里排序的习惯，那附近的公里是怎么设计的呢？今天shigen带你一起揭秘。

分析

我们先明确一下需求，每个商家都有一个地址对吧，我们也有一个地址，我们点餐的时候，就是以我们自己所在的位置为圆心，向外辐射，这一圈上有一堆的商家。类似我下方的图展示：

想到了位置，我们自然想到了卫星定位，想到了二维的坐标。那这个需求我们有什么好的设计方案吗？

redis的GEO地理位置坐标这个数据结构刚好能解决我们的需求。

GEO

GEO 是一种地理空间数据结构，它可以存储和处理地理位置信息。它以有序集合（Sorted Set）的形式存储地理位置的经度和纬度，以及与之关联的成员。

以下是 Redis GEO 的一些常见操作：

0. GEOADD key longitude latitude member [longitude latitude member ...]：将一个或多个地理位置及其成员添加到指定的键中。 示例：GEOADD cities -122.4194 37.7749 "San Francisco" -74.0059 40.7128 "New York"


1. GEODIST key member1 member2 [unit]：计算两个成员之间的距离。 示例：GEODIST cities "San Francisco" "New York" km


2. GEOPOS key member [member ...]：获取一个或多个成员的经度和纬度。 示例：GEOPOS cities "San Francisco" "New York"


3. GEORADIUS key longitude latitude radius unit [WITHCOORD] [WITHDIST] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]：根据给定的经纬度和半径，在指定范围内查找与给定位置相匹配的成员。 示例：GEORADIUS cities -122.4194 37.7749 100 km WITHDIST COUNT 5

前言

经常浏览小视频或各类帖子的朋友们可能已经注意到，目前许多网络平台都会显示作者和评论区用户的IP归属地。那么，这个功能是如何实现的呢？

某些收费平台的API

我们可以利用一些付费平台的API来实现这一功能，比如一些导航软件的开放平台API等。然而，这些服务通常是收费的，而且免费额度有限，适合测试使用，但如果要在生产环境中使用，很可能不够支撑需求。

离线库推荐

那么，有没有免费的离线API库呢？UP现在推荐一个强大的离线库给大家，一个准确率高达99.9%的离线IP地址定位库，查询速度仅需0.0x毫秒，而且数据库仅10兆字节大小。此库提供了Java、PHP、C、Python、Node.js、Golang、C#等多种查询绑定，同时支持Binary、B树和内存三种查询算法。

这个库大家可以在GitHub上搜索：ip2region，即可找到该开源库。

使用

下面使用Java代码给大家演示下如何使用这个IP库，该库目前支持多重主流语言。

1、引入依赖

<dependency>

    <groupId>org.lionsoul</groupId>

    <artifactId>ip2region</artifactId>

    <version>2.7.0</version>

</dependency>

2、下载离线库文件 ip2region.xdb

3、简单使用代码

下面，我们通过Java代码，挑选某个国内的IP进行测试，看看会输出什么样的结果

public class IpTest {

​

    public static void main(String[] args) throws Exception {

        // 1、创建 searcher 对象 (修改为离线库路径)

        String dbPath = "C:\Users\Administrator\Desktop\ip2region.xdb";

        Searcher searcher = null;

        try {

            searcher = Searcher.newWithFileOnly(dbPath);

        } catch (Exception e) {

            System.out.printf("failed to create searcher with `%s`: %s\n", dbPath, e);

            return;

        }

​

        // 2、查询

        String ip = "110.242.68.66";

        try {

            long sTime = System.nanoTime(); // Happyjava

            String region = searcher.search(ip);

            long cost = TimeUnit.NANOSECONDS.toMicros((long) (System.nanoTime() - sTime));

            System.out.printf("{region: %s, ioCount: %d, took: %d μs}\n", region, searcher.getIOCount(), cost);

        } catch (Exception e) {

            System.out.printf("failed to search(%s): %s\n", ip, e);

        }

​

        // 3、关闭资源

        searcher.close();

​

        // 备注：并发使用，每个线程需要创建一个独立的 searcher 对象单独使用。

    }

​

}

​

输出结果为：

{region: 中国|0|河北省|保定市|联通, ioCount: 3, took: 1192 μs}

其中，region的格式为 国家|区域|省份|城市|ISP，缺省的地域信息默认是0。

当然，这个库不只是支持国内的IP，也支持国外的IP。

其他语言可以参考该开源库的说明文档。

总结

这是一个准确率非常高的离线库，如果项目里有IP定位需求的，可以试下该库。

在一些前端开发场景中，需要在本地创建 https 服务，Node.js 提供了 https 模块帮助开发者快速创建 https 的服务器，示例代码如下：

const https = require('https')

const fs = require('fs')

const options = {

  key: fs.readFileSync('key.pem'),

  cert: fs.readFileSync('cert.pem'),

}

const server = https.createServer(options, (req, res) => {

  res.writeHead(200)

  res.end('hello world\n')

})

server.listen(8080)

与创建 http 服务最大的区别在于：https 服务需要证书。因此需要在 options 选项中提供 key 和 cert 两个字段。大部分前端不知道如何创建 key 和 cert，虽然网上能查到一些 openssl 命令，但也不知道是什么含义。所谓授人以鱼不如授人以渔，这里先从一些基本概念讲起，然后一步步教大家如何创建一个可以被浏览器绝对信任的自签名证书。

密码学知识

首先要知道加密学中非常重要的一个算法：公开密钥算法（Public Key Cryptography），也称为非对称加密算法（Asymmetrical Cryptography），算法的密钥是一对，分别是公钥（public key）和私钥（private key），一般私钥由密钥对的生成方（比如服务器端）持有，避免泄露，而公钥任何人都可以持有，也不怕泄露。

一句话总结：公钥加密、私钥解密。

公私钥出了用于加解密之外，还能用于数字签名。因为私钥只有密钥对的生成者持有，用私钥签署（注意不是加密）一条消息，然后发送给任意的接收方，接收方只要拥有私钥对应的公钥，就能成功反解被签署的消息。

一句话总结：私钥加签、公钥验证。

由于只有私钥持有者才能“签署”消息，如果不考虑密钥泄露的问题，就不能抵赖说不是自己干的。

数字签名和信任链

基于数字签名技术，假设 A 授权给 B，B 授权给 C，C 授权给 D，那么 D 就相当于拿到了 A 的授权，这就形成了一个完整的信任链。因此：

• 信任链建立了一条从根证书颁发机构（Root CA）到最终证书持有人的信任路径


• 每个证书都有一个签名，验证这个签名需要使用颁发该证书的机构的公钥


• 信任链的作用是确保接收方可以验证数字签名的有效性，并信任签名所代表的身份

以 https 证书在浏览器端被信任为例，整个流程如下：

可以看到，在这套基础设施中，涉及到很多参与方和新概念，例如：

• 服务器实体：需要申请证书的实体（如某个域名的拥有者）


• CA机构：签发证书的机构


• 证书仓库：CA 签发的证书全部保存到仓库中，证书可能过期或被吊销。


• 证书校验方：校验证书真实性的软件，例如浏览器、客户端等。

这些参与方、概念和流程的集合被称为公钥基础设施（Public Key Infrastructure）

X.509 标准

为了能够将这套基础设施跑通，需要遵循一些标准，最常用的标准是 X.509，其内容包括：

• 如何定义证书文件的结构（使用 ANS.1 来描述证书）


• 如何管理证书（申请证书的流程，审核身份的标准，签发证书的流程）


• 如何校验证书（证书签名校验，校验实体属性，比如的域名、证书有效期等）


• 如何对证书进行撤销（包括 CRL 和 OCSP 协议等概念）

X.509标准在网络安全中广泛使用，特别是在 TLS/SSL 协议中用于验证服务器和客户端的身份。在 Node.js 中，当 tls 通道创建之后，可以通过下面两个方法获取客户端和服务端 X.509 证书：

• 获取本地 X.509 证书：getX509Certificate


• 获取对方 X.509 证书：getPeerX509Certificate

生成证书

要想生成证书，首要有一个私钥（private key），私钥的生成方式为：

$ openssl genrsa -out key.pem 2048

会生成一个 key.pem 文件，内容如下：

-----BEGIN PRIVATE KEY-----

MIIEvgIBADANBgkqhkiG9w0BAQEFAASCB....

-----END PRIVATE KEY-----

然后，还需要一个与私钥相对应的公钥（public key），生成方式：

$ openssl req -new -sha256 -key key.pem -out csr.pem

按照提示操作即可，下面是示例输入（中国-浙江省-杭州市-西湖-苏堤-keliq）：

You are about to be asked to enter information that will be incorporated

int0 your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:CN

State or Province Name (full name) [Some-State]:Zhejiang

Locality Name (eg, city) []:Hangzhou

Organization Name (eg, company) [Internet Widgits Pty Ltd]:West Lake

Organizational Unit Name (eg, section) []:Su Causeway

Common Name (e.g. server FQDN or YOUR name) []:keliq

Email Address []:email@example.com   



Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:123456

An optional company name []:XiHu

生成的文件内容如下：

-----BEGIN CERTIFICATE REQUEST-----

MIIDATCCAekCAQAwgY8xCzAJBgNVBAYTAkNOMREw...

-----END CERTIFICATE REQUEST-----

公钥文件创建之后，接下来有两个选择：

• 将其发送给 CA 机构，让其进行签名


• 自签名

自签名

如果是本地开发，我们选择自签名的方式就行了，openssl 同样提供了命令：

$ openssl x509 -req -in csr.pem -signkey key.pem -out cert.pem

Certificate request self-signature ok

subject=C = CN, ST = Zhejiang, L = Hangzhou, O = West Lake, OU = Su Causeway, CN = keliq, emailAddress = email@example.com

最终得到了 cert.pem，内容如下：

-----BEGIN CERTIFICATE-----

MIIDpzCCAo8CFAf7LQmMUweTSW+ECkjc7g1uy3jCMA0...

-----END CERTIFICATE-----

到这里，所有环节都走完了，再来回顾一下，总共生成了三个文件，环环相扣：

• 首先生成私钥文件 key.pem


• 然后生成与私钥对应的公钥文件 csr.pem


• 最后用公私钥生成证书 cert.pem

实战——信任根证书

用上面自签名创建的证书来创建 https 服务：

const options = {

  key: fs.readFileSync('key.pem'),

  cert: fs.readFileSync('cert.pem'),

}

启动之后，如果你在浏览器中访问，会发现出错了：

命名是 https 服务，为什么浏览器说不是私密连接呢？因为自签名证书默认是不被浏览器信任的，只需要将 cert.pem 拖到钥匙里面即可，然后修改为「始终信任」，过程中需要验证指纹或者输入密码：

如果你觉得上述流程比较繁琐，可以用下面的命令行来完成：

$ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain cert.pem

实战——指定主题备用名称

然而，即使添加了钥匙串信任，问题似乎并没有解决，报错还是依旧：

仔细看，其实报错信息发生了变化，从原来的 NET::ERR_CERT_AUTHORITY_INVALID 变成了 NET::ERR_CERT_COMMON_NAME_INVALID，这又是怎么回事呢？我们点开高级按钮看一下详细报错：

这段话的意思是：当前网站的 SSL 证书中的通用名称（Common Name）与实际访问的域名不匹配。

证书中会包含了一个通用名称字段，用于指定证书的使用范围。如果证书中的通用名称与您访问的域名不匹配，浏览器会出现NET::ERR_CERT_COMMON_NAME_INVALID错误。

一句话描述，证书缺少了主题备用名称（subjectAltName），而浏览器校验证书需要此字段。为了更好的理解这一点，我们可以用下面的命令查看证书的完整信息：

$ openssl x509 -in cert.pem -text -noout

输出结果如下：

Certificate:

    Data:

        Version: 1 (0x0)

        Serial Number:

            07:fb:2d:09:8c:53:07:93:49:6f:84:0a:48:dc:ee:0d:6e:cb:78:c2

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: C = CN, ST = Zhejiang, L = Hangzhou, O = West Lake, OU = Su Causeway, CN = keliq, emailAddress = email@example.com

        Validity

            Not Before: Nov 15 06:29:36 2023 GMT

            Not After : Dec 15 06:29:36 2023 GMT

        Subject: C = CN, ST = Zhejiang, L = Hangzhou, O = West Lake, OU = Su Causeway, CN = keliq, emailAddress = email@example.com

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:ac:63:b1:f1:7a:69:aa:84:ef:9d:0e:be:c1:f7:

                    80:3f:6f:59:e1:7d:c5:c6:db:ff:2c:f3:99:12:7f:

                    ...

                Exponent: 65537 (0x10001)

    Signature Algorithm: sha256WithRSAEncryption

    Signature Value:

        70:d9:59:10:46:dc:7b:b3:19:c8:bd:4b:c5:70:4f:89:b6:6a:

        53:1c:f2:35:27:c8:0a:ed:a8:0a:13:1f:46:3e:e7:a7:ff:1f:

        ...

我们发现，这个证书并没有 Subject Alternative Name 这个字段，那如何增加这个字段呢？有两种方式：

指定 extfile 选项

$ openssl x509 -req \

  -in csr.pem \

  -signkey key.pem \

  -extfile <(printf "subjectAltName=DNS:localhost") \

  -out cert.pem

再次用命令查看证书详情，可以发现 Subject Alternative Name 字段已经有了：

...

X509v3 extensions:

    X509v3 Subject Alternative Name: 

        DNS:localhost

    X509v3 Subject Key Identifier: 

        21:65:8F:93:49:BC:DF:8C:17:1B:6C:43:AC:31:3C:A9:34:3C:CB:77

...

用新生成的 cert.pem 启动 https 服务，再次访问就正常了，可以点击小锁查看证书详细信息：

但是如果把 localhost 换成 127.0.0.1 的话，访问依然被拒绝，因为 subjectAltName 只添加了 localhost 这一个域名，所以非 localhost 域名使用此证书的时候，浏览器就会拒绝。

新建 .cnf 文件

这次我们新建一个 ssl.cnf 文件，并在 alt_names 里面多指定几个域名：

[req]

prompt = no

default_bits = 4096

default_md = sha512

distinguished_name = dn

x509_extensions = v3_req



[dn]

C=CN

ST=Zhejiang

L=Hangzhou

O=West Lake

OU=Su Causeway

CN=keliq

emailAddress=keliq@example.com



[v3_req]

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName=@alt_names



[alt_names]

DNS.1 = localhost

IP.2 = 127.0.0.1

IP.3 = 0.0.0.0

然后一条命令直接生成密钥和证书文件：

$ openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 \

  -config openssl.cnf \

  -keyout key.pem \

  -out cert.pem 

再次查看证书详情，观察 Subject Alternative Name 字段：

...

X509v3 extensions:

      X509v3 Key Usage: 

          Digital Signature, Non Repudiation, Key Encipherment

      X509v3 Subject Alternative Name: 

          DNS:localhost, IP Address:127.0.0.1, IP Address:0.0.0.0

      X509v3 Subject Key Identifier: 

          B6:FC:1E:68:CD:8B:97:D0:80:0E:F1:18:D3:39:86:29:90:0B:9D:1F

...

这样无论是访问 localhost 还是 127.0.0.1 或者 0.0.0.0，浏览器都能够信任。

如果您听说过Service Mesh并尝试过Istio，您可能会有以下问题：

本文将带您了解 Kubernetes 和 Istio 的内部工作原理。另外，我还会介绍 Kubernetes 中的负载均衡方法，并解释为什么有了 Kubernetes 还需要 Istio。

Kubernetes 本质上是通过声明性配置进行应用程序生命周期管理，而服务网格本质上是提供应用程序间流量、安全管理和可观察性。如果你已经使用 Kubernetes 搭建了一个稳定的应用平台，那么如何为服务之间的调用设置负载均衡和流量控制呢？这就是服务网格发挥作用的地方。

Envoy 引入了 xDS 协议，该协议受到各种开源软件的支持，例如Istio、MOSN等。Envoy 将 xDS 贡献给服务网格或云原生基础设施。Envoy 本质上是一个现代版本的代理，可以通过 API 进行配置，并基于它衍生出许多不同的使用场景——例如 API 网关、服务网格中的 sidecar 代理和边缘代理。

本文包含以下内容：

• kube-proxy 作用的描述。


• Kubernetes 对于微服务管理的局限性。


• 介绍 Istio 服务网格的功能。


• Kubernetes、Envoy 和 Istio 服务网格中一些概念的比较。

Kubernetes 与服务网格

下图展示了 Kubernetes 和 Service Mesh（每个 pod 一个 sidecar 模型）中的服务访问关系。

流量转发

Kubernetes 集群中的每个节点都会部署一个 kube-proxy 组件，该组件与 Kubernetes API Server 通信，获取集群中服务的信息，然后设置 iptables 规则，将服务请求直接发送到对应的 Endpoint（属于该集群的 pod）。同一组服务）。

服务发现

Istio 可以跟随 Kubernetes 中的服务注册，还可以通过控制平面中的平台适配器与其他服务发现系统对接；然后使用数据平面的透明代理生成数据平面配置（使用 CRD，存储在 etcd 中）。数据平面的透明代理作为sidecar容器部署在每个应用服务的pod中，所有这些代理都需要请求控制平面同步代理配置。代理是“透明的”，因为应用程序容器完全不知道代理的存在。该进程中的 kube-proxy 组件也需要拦截流量，只不过 kube-proxy 拦截进出 Kubernetes 节点的流量，而 sidecar 代理拦截进出 pod 的流量。

服务网格的缺点

由于 Kubernetes 每个节点上运行有很多 pod，将原有的 kube-proxy 路由转发功能放在每个 pod 中会增加响应延迟（由于 sidecar 拦截流量时的跳数更多）并消耗更多资源。为了以细粒度的方式管理流量，将添加一系列新的抽象。这会进一步增加用户的学习成本，但随着技术的普及这种情况会慢慢得到缓解。

服务网格的优点

kube-proxy 设置是全局的，无法对每个服务进行精细控制，而服务网格通过 sidecar 代理将流量控制从 Kubernetes 的服务层中取出，从而实现更大的弹性。

Kube-Proxy 的缺点

首先，如果转发的 Pod 无法正常服务，它不会自动尝试另一个 Pod。每个 pod 都有健康检查机制，当 pod 出现健康问题时，kubelet 会重启 pod，kube-proxy 会删除相应的转发规则。此外，nodePort 类型的服务无法添加 TLS 或更复杂的消息路由机制。

Kube-proxy 实现了 Kubernetes 服务的多个 pod 实例之间的流量负载均衡，但是如何对这些服务之间的流量进行细粒度控制——例如将流量按百分比划分到不同的应用程序版本（这些版本都是同一个应用程序的一部分）服务但在不同的部署上），或者进行灰度发布和蓝绿发布？

Kubernetes 社区提供了一种使用 Deployment 进行灰度发布方法，这本质上是一种通过修改 pod 标签将不同 pod 分配给部署服务的方法。

Kubernetes Ingress 与 Istio 网关

如上所述，kube-proxy 只能在 Kubernetes 集群内路由流量。Kubernetes 集群的 Pod 位于 CNI 创建的网络中。入口（在 Kubernetes 中创建的资源对象）是为了集群外部的通信而创建的。它由位于 Kubernetes 边缘节点上的入口控制器驱动，负责管理南北流量。Ingress 必须对接各种 Ingress Controller，例如nginx ingress 控制器。Ingress仅适用于HTTP流量，使用简单。它只能通过匹配有限数量的字段（例如服务、端口、HTTP 路径等）来路由流量。这使得无法路由 MySQL、Redis 和各种 RPC 等 TCP 流量。这就是为什么你会看到人们在入口资源注释中编写 nginx 配置语言。直接路由南北流量的唯一方法是使用服务的 LoadBalancer 或 NodePort，前者需要云供应商支持，后者需要额外的端口管理。

Istio Gateway 的功能与 Kubernetes Ingress 类似，负责进出集群的南北向流量。Istio Gateway 描述了一种负载均衡器，用于承载进出网格边缘的连接。该规范描述了一组开放端口以及这些端口使用的协议、用于负载均衡的 SNI 配置等。 Gateway 是一个 CRD 扩展，它也重用了 sidecar 代理的功能；详细配置请参见Istio 网站。

Envoy

Envoy 是 Istio 中默认的 sidecar 代理。Istio 基于 Enovy 的 xDS 协议扩展了其控制平面。在谈论 Envoy 的 xDS 协议之前，我们需要先熟悉一下 Envoy 的基本术语。以下是 Envoy 中的基本术语及其数据结构列表；请参阅Envoy 文档了解更多详细信息。

基本术语

以下是您应该了解的 Enovy 基本术语。

• Downstream：下游主机连接 Envoy，发送请求，接收响应；即发送请求的主机。


• Upstream：上游主机接收来自 Envoy 的连接和请求并返回响应；即接收请求的主机。


• Listener：Listener 是一个命名的网络地址（例如端口、UNIX 域套接字等）；下游客户端可以连接到这些侦听器。Envoy 向下游主机公开一个或多个侦听器以进行连接。


• Cluster：集群是 Envoy 连接的一组逻辑上相同的上游主机。Envoy 通过服务发现来发现集群的成员。或者，可以通过主动健康检查来确定集群成员的健康状态。Envoy 通过负载均衡策略决定集群中的哪个成员来路由请求。

Envoy 中可以设置多个监听器，每个监听器可以设置一个过滤器链（过滤器链表），并且过滤器是可扩展的，以便我们可以更轻松地操纵流量的行为——例如设置加密、私有 RPC 等。

xDS 协议由 Envoy 提出，是 Istio 中默认的 sidecar 代理，但只要实现了 xDS 协议，理论上就可以在 Istio 中用作 sidecar 代理——比如蚂蚁集团开源的MOSN。

Istio 是一个功能非常丰富的服务网格，包括以下功能。

• 流量管理：这是Istio最基本的功能。


• 策略控制：启用访问控制系统、遥测捕获、配额管理、计费等。


• 可观察性：在 sidecar 代理中实现。


• 安全身份验证：Citadel 组件执行密钥和证书管理。

Istio 中的流量管理

Istio 中定义了以下 CRD 来帮助用户进行流量管理。

• 网关：网关描述了运行在网络边缘的负载均衡器，用于接收传入或传出的 HTTP/TCP 连接。


• VirtualService：VirtualService 实际上将 Kubernetes 服务连接到 Istio 网关。它还可以执行其他操作，例如定义一组在寻址主机时应用的流量路由规则。


• DestinationRule：DestinationRule 定义的策略决定流量经过路由后的访问策略。简而言之，它定义了流量的路由方式。其中，这些策略可以定义为负载均衡配置、连接池大小和外部检测（用于识别并驱逐负载均衡池中不健康的主机）配置。


• EnvoyFilter：EnvoyFilter 对象描述代理服务的过滤器，可以自定义 Istio Pilot 生成的代理配置。这种配置一般初级用户很少使用。


• ServiceEntry：默认情况下，Istio 服务网格中的服务无法发现网格之外的服务。ServiceEntry 允许将其他条目添加到 Istio 内的服务注册表中，从而允许网格中自动发现的服务访问并路由到这些手动添加的服务。

Kubernetes、xDS、Istio

回顾了 Kubernetes 的 kube-proxy 组件、xDS 和 Istio 中流量管理的抽象之后，现在让我们仅在流量管理方面对这三个组件/协议进行比较（请注意，这三个组件并不完全相同）。

要点

• Kubernetes 的本质是应用程序生命周期管理，特别是部署和管理（伸缩、自动恢复、发布）。


• Kubernetes 为微服务提供了可扩展且高弹性的部署和管理平台。


• 服务网格基于透明代理，通过 sidecar 代理拦截服务之间的流量，然后通过控制平面配置管理它们的行为。


• 服务网格将流量管理与 Kubernetes 解耦，无需 kube-proxy 组件来支持服务网格内的流量；通过提供更接近微服务应用程序层的抽象来管理服务间流量、安全性和可观察性。


• xDS 是服务网格配置的协议标准之一。


• 服务网格是 Kubernetes 中服务的更高级别抽象。

概括

如果说 Kubernetes 管理的对象是 Pod，那么 Service Mesh 管理的对象就是服务，所以只要用 Kubernetes 来管理微服务，然后应用 Service Mesh 就可以了。如果您甚至不想管理服务，那么可以使用像Knative这样的无服务器平台z。

最近五阳遇到了线上资损问题，我开始重视分布式事务的数据一致性问题，拿我擅长的场景分析下。

举个🌰例子

在付费会员场景，用户购买会员后享受会员权益。在会员售后场景，用户提交售后，系统需要冻结权益并且原路赔付退款。

系统如何保证冻结权益和订单退款的数据一致性呢？当无法保证数据一致时，会导致什么问题呢？

通过这个例子可以看到电商场景中，数据不一致可能会导致资金损失。这是电商场景对数据一致性要求高的原因，很多资损（资金损失）问题都是源于数据不一致。

如何理解数据一致性，一致性体现在哪里?

狭义上的数据一致是指：数据完全相同，在数据库主从延迟场景，主从数据一致是指：主数据副本和从数据副本，数据完全相同，客户端查询主库和查询从库得到的结果是相同的，也就是一致的。

除数据多副本场景使用数据一致性的概念之外，扩展后其他场景也使用这个概念。例如分布式事务中，多个事务参与者各自维护一种数据，当多种数据均处于合法状态且符合业务逻辑的情况下，那就可以说整体处于数据一致了。（并不像副本场景要求数据完全相同）

例如会员订单有支付状态和退款状态，会员优惠券有未使用状态和冻结状态。 在一次分布式事务执行前后，订单和优惠券的状态是一致的，即会员订单退款、会员券冻结；会员订单未退款，会员券状态为可使用；

此外还有异构数据一致性，超时一致。异构数据一致性是指同一种数据被异构到多种存储中间件。例如本地缓存、Redis缓存和数据库，即三级缓存的数据一致性。还有搜索场景，需要保证数据库数据和 ElasticSearch数据一致性，这也是分布式事务问题。

一致性和原子性的区别

原子性 指的是事务是一个不可分割的最小工作单元，事务中的操作要么全部成功，要么全部失败。

一致性 指的是事务执行前后，所有数据均处于一致性状态，一致性需要原子性的支持。如果没有实现原子性，一致性也无法实现。一致性在原子性的基础上，还要求实现数据的正确性。例如在同一个事务中实现多商品库存扣减，多个SQL除了保证同时成功同时失败外，还需要保证操作的正确性。如果所有SQL都返回成功了，但是数据是错误的，这无法接受。这就是一致性的要求。

由此可见，数据一致性本身就要求了数据是正确的。

隔离性是指：其他事务并发访问同一份数据时，多个事务之间应该保持隔离性。隔离性级别：如读未提交、‌读已提交、‌可重复读和串行化。

隔离性强调的是多个事务之间互不影响的程度，一致性强调的是一个事务前后，数据均处于一致状态。

什么是强一致性

在分布式事务场景，强一致性是指：任何一个时刻，看到各个事务参与者的数据都是一致的。系统不存在不一致的情况。

值得一提的是，CAP理论指出，数据存在多副本情况下，要保证强一致性（在一个绝对时刻，两份数据是完全一致的）需要牺牲可用性。

也就是说系统发现自身处于不一致状态时，将向用户返回失败状态。直至数据一致后，才能返回最新数据，这将牺牲可用性。

为了保证系统是可用的，可以返回旧的数据，但是无法保证强一致性。

会员售后能保证强一致性吗？

会员售后关键的两个动作：权益冻结和订单退款。 两者能保证强一致性吗？答案是不能。假设权益冻结是一个本地事务性操作，但是订单退款包括订单状态流程、支付系统资金流转等等。

如此复杂的流程难以保证任意一个绝对时刻，用户看到权益冻结后，资金一定到账了；这是售后场景 无法达到强一致性的根本原因。

最终一致性和强一致性

最终一致性不要求系统在任意一个时刻，各参与方数据都是一致的，它要求各参与方数据在一定时间后处于一致状态。

最终一致性没有明确这个时间是多长，所以有人说最终一致性就是没有一致性，谁知道多久一定能保证一致呢。

保证最终一致性的手段有哪些？

TCC

TCC 包含 Try、Confirm 和 Cancel 三个操作。

需要说明，如果Confirm执行失败，需要不停不重试Confirm，不得执行Cancel。 按照TCC的语义 Try操作已经锁定了、预占了资源。 Confirm在业务上一定是可以成功的。

TCC的问题在于 分布式事务的任意一个操作都应该提供三个接口，每个参与者都需要提供三个接口，整体交互协议复杂，开发成本高。当发生嵌套的分布式事务时，很难保证所有参与者都实现TCC规范。

为什么TCC 方案包含Try

如果没有Try阶段，只有Confirm和 Cancel阶段，如果Confirm失败了，则调用Cancel回滚。为什么Tcc不这样设计呢？

引入Try阶段，为保证不发生状态回跳的情况。

Try阶段是预占资源阶段，还未实际修改资源。设想资金转账场景， A账户向B账户转账100元。 在Try阶段 A账户记录了预扣100元，B 账户记录了预收100元。 如果A账户不足100元，那么Try阶段失败，调用Cancel回滚，这种情况，在任意时刻，A、B用户视角转账是失败的。

Try阶段成功，则调用Confirm接口，最终A账户扣100元，B收到100元。虽然这无法保证在某个时刻，A、B账户资金绝对一致。但是如果没有Try阶段，那么将发生 状态回跳的情况；

状态回跳：即A账户操作成功了，但是B账户操作失败，A账户资金又被回滚了。那么用户A 看到自己的账户状态就是 钱被扣了，但是过一会钱又回来了。

同理B账户也可能遇到收到钱了，但是过一会钱又没了。在转账场景，这种回跳情况几乎是不能接受的。

引入了Try阶段，就能保证不发生状态回跳的情况。

最大努力通知

最大努力通知是指通知方通过一定的机制最大努力将业务处理结果通知到接收方。一般用于最终一致性时间敏感度低的场景，并且接收方的结果不会影响到发起方的结果。即接收方处理失败时，发送方不会跟随回滚。

在电商场景，很多场景使用最大努力通知型作为数据一致性方案。

会员售后如何保证最终一致性？

回到开头的问题，以下是数据不一致的两种情况。

平台资损难以追回，当发生容易复现的平台资损时，会引来更多的用户“薅羊毛”，资损问题将进一步放大，所以平台资损一定要避免。

当发生用户资损时，用户可以通过客服向平台追诉，通过人工兜底的方式，可以保证“最终”数据是一致的。

所以基于这个大的原则，大部分系统都是优先冻结会员权益，待用户权益明确冻结后，才根据实际冻结情况，向用户退款。这最大程度上保证了售后系统的资金安全。

会员售后整体上是最大努力通知一致性方案。当权益冻结后，系统通过可重试的消息触发订单退款，且务必保证退款成功（即便是人工介入情况下）。虽说是最大努力通知型，但不代表一致性弱，事实上支付系统的稳定性要求是最高级别的，订单退款成功的可靠性是能得到保证的。

如果权益冻结是分布式事务，如何保证一致性

一开始我们假设权益冻结是一个本地事务，能保证强一致性，这通常与实际不符。权益包含很多玩法，例如优惠券、优惠资格、会员日等等，权益冻结并非是本地事务，而是分布式事务，如何保证一致性呢？

方案1 TCC方案

假设 权益系统包含三个下游系统，身份系统（记录某个时间段是会员）、优惠券系统、优惠资格系统。 TCC方案将要求三方系统均实现 Try、Confirm、Cancel接口。开发成本和上下游交付协议比较复杂。

方案2 无Try 的 TCC方案

假设无Try阶段，直接Confirm修改资源，修改失败则调用Cancel，那么就会出现状态跳回情况，即优惠券被冻结了，但是后面又解冻了。

这种情况下，系统只需要实现扣减资源和回滚资源 两种接口。 系统设计大大简化

方案3 Prepare + Confirm

Prepare: 检查接口，即检查资源是否可以被修改，但是不会锁定资源。

Confirm: 修改资源接口，实际修改资源状态。

如果Prepare失败，则返回执行失败，由于未预占用资源，所以无需回滚资源。在Prepare成功后，则立即调用Confirm。如果Confirm执行失败，则人工介入。

一定需要回滚吗？

在一致性要求高的场景，需要资源回滚能力，保证系统在一定时间后处于一致状态。如果没有回滚，势必导致在某些异常情况下，系统处于不一致状态，且无法自动恢复。

会员售后场景虽然对资金较为敏感，但不需要资源回滚。理由如下

在上述方案3中，先通过Prepare阶段验证了参与方都是可以冻结的，在实际Confirm阶段这个状态很难发生改变。所以大概率Confirm不会失败的。

只有极低的概率发生Confirm失败的情况，即用户在权益冻结的一瞬间，使用优惠券，这将导致资源状态发生改变。

解决此类问题，可以在权益冻结后，评估冻结结果，根据实际的冻结结果，决定如何赔付用户，赔付用户多少钱。所以用户并发用券，也不会影响资金安全。

人工兜底与数据一致性

程序员应该在业务收益、开发成本、数据不一致风险等多个角度评估系统设计的合理性。

会员售后场景，看似数据一致性要求高，仿佛数据不一致，就会产生严重的资损问题。但实际分析后，系统并非需要严格的一致性。

越是复杂的系统设计，系统稳定性越差。越是简洁的系统设计，系统稳定性越高。当选择了复杂的系统设计提高数据一致性，必然需要付出更高的开发成本和维护成本。往往适得其反。

当遇到数据一致性挑战时，不妨跳出技术视角，尝试站在产品视角，思考能否适当调整一下产品逻辑，容忍系统在极端情况下，有短暂时间数据不一致。人工兜底处理极端情况。

大多数情况下，产品经理会同意。

Docker容器日志过大？有没有比较简单的方式解决？

1. 问题描述

当我们尝试查看特定 Docker 容器的日志时，通常会使用 docker logs <容器名称> 命令。然而，有时候会发现控制台持续输出日志信息，持续时间可能相当长，直到最终打印完成。这种现象往往源自对 Docker 容器日志长时间未进行处理，导致日志积累过多，占用了系统磁盘空间。因此，为了释放磁盘空间并优化系统性能，我们可以采取一些简单而有效的方法来处理这些庞大的日志文件。

2. docker日志处理机制

需要处理问题，那我们肯定要先了解docker的日志处理机制，了解了基本的机制，能够帮助我们更好的理解问题并解决问题。

2.1 日志查看

docker logs <容器名称>可以查看docker容器的输出日志，但是这里的日志主要包含标准输出和标准错误输出，一些容器可能会把日志输出到某个日志文件中，比如tomcat，这样使用docker logs <容器名称>命令是无法查看的。

注意docker logs命令查看的是容器的全部日志，当日志量很大时会对容器的运行造成影响，可以通过docker logs --tail N container name查看最新N行的数据，N是一个整数。

2.2 处理机制

当我们启动一个docker容器时，实际上时作为docker daemon的一个子进程运行的，docker daemon可以拿到容器里进程的标准输出与标准错误输出，并通过docker的log driver模块来处理，大致图示如下：

上面图中所列举的就是所支持的Log Driver：

• none：容器没有日志，docker logs不输出任何内容


• local：日志以自定义格式存储


• json-file：日志以json格式存储，默认的Log Driver


• syslog：将日志写入syslog。syslog守护程序必须在主机上运行


• journald：将日志写入journald。journald守护程序必须在主机上运行


• gelf：将日志写入Graylog Extended Log Format端点，如Graylog或Logstash


• fluentd：将日志写入fluentd。fluentd守护程序必须在主机上运行


• awslogs：将日志写入Amazon CloudWatch Logs


• splunk：通过HTTP Event Collector将日志写入splunk


• etwlogs：将日志作为ETW（Event Tracing for Windows）事件写入。只在Windows平台可用


• gcplogs：将日志写入Google Cloud Platform Logging


• logentries：将日志写入Rapid7 Logentries

可以使用命令docker info | grep "Logging Driver"

2.3 默认的json-file

json-file Log Driver是Docker默认启用的Driver，将容器的STDOUT/STDERR输出以json的格式写到宿主机的磁盘，日志文件路径为 /var/lib/docker/containers/{container_id}/{container_id}-json.log

格式是这样的：

json-file将每一行日志封装到一个json字符串中。

json-file支持如下配置：

• max-size：单个日志文件的最大大小，单位可以为k、m、g，默认是-1，表示日志文件可以无限大。


• max-file：最多可以存多少个日志文件，默认数量是1，当默认数量大于1时，每个日志文件达到最大存储大小，且数量达到设置数量，产生新日志时会删除掉最旧的一个日志文件。


• labels：指定日志所使用到的标签，使用逗号分割。比如traceId,message两个标签。


• env：指定与日志相关的环境变量，使用逗号分割


• env-rejex：一个正则表达式来匹配与日志相关的环境变量


• compress：是否压缩日志文件

3. 如何解决？

3.1 查看日志大小

我们可以通过如下脚本获取当前所有容器的日志大小，这里时使用docker默认的json-file的形式：

#!/bin/sh 

echo "======== docker containers logs file size ========"  



logs=$(find /var/lib/docker/containers/ -name *-json.log)



for log in $logs

do

    ls -lh $log

done

执行脚本：

json-file的命令开头的一小串字符时容器的id。

例如我有一个docker容器id是2de6f164ee11，我们可以适当修改shell脚本，查看某一个容器的日志大小。

logs=$(find /var/lib/docker/containers/ -name *-json.log | grep "2de6f164ee11")

3.2 删除日志

如果docker容器正在运行，使用rm -rf的方式删除日志后，磁盘空间并没有释放。原因是在Linux或者Unix系统中，通过rm -rf或者文件管理器删除文件，将会从文件系统的目录结构上解除链接（unlink）。如果文件是被打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用。

正确的方式是直接使用命令改写日志文件。

cat /dev/null > *-json.log

• cat: 是一个命令，用于连接文件并打印它们的内容到标准输出（通常是终端）。


• /dev/null: 是一个特殊的设备文件，向它写入的内容会被丢弃，读取它将会立即返回结束符。


• >: 是重定向操作符，将命令的输出重定向到文件。


• *-json.log: 是通配符，用于匹配当前目录中所有以 -json.log 结尾的文件。

可以使用如下脚本，直接处理所有的日志文件：

#!/bin/sh 

echo "======== start clean docker containers logs ========"  



logs=$(find /var/lib/docker/containers/ -name *-json.log)



for log in $logs

        do

                echo "clean logs : $log"  

                cat /dev/null > $log

        done



echo "======== end clean docker containers logs ========"

注意，虽然使用这种方式可以删除日志，释放磁盘，但是过一段时间后，日志又会涨回来，所以要从根本上解决问题，只需要添加两个参数。没错！就是上面所讲到的max-size和max-file。

3.3 治本操作

在运行docker容器时，添加上max-size和max-file可以解决日志一直增长的问题。

docker run -it --log-opt max-size=10m --log-opt max-file=3 alpine ash

这段启动命令表示总共有三个日志文件，每个文件的最大大小时10m，这样就能将该容器的日志大小控制在最大30m。

4. 总结

在运行容器时，我们就应该优先考虑如何处理日志的问题，后面不必为容器运行后所产生的巨大日志而手足无措。

当然需要删除无用日志可以通过3.1，3.2的操作完成，建议在运行容器的时候加上max-size和max-file参数或者至少加上max-size参数。

前言

最近闲来没事，一直在掘金上摸鱼，看了不少高并发相关的文章，突然有感而发，想到了几年前做的一个项目，也多少和高并发有点关系。

这里我一边回忆落地细节一边和大家分享下，兴许能给大家带来点灵感。

正文

需求及背景

先来介绍下需求，首先项目是一个志愿填报系统。

核心功能是两块，一是给考试填报志愿，二是给老师维护考生数据。

本来这个项目不是我们负责，奈何去年公司负责这个项目的组遭到了甲方严重的投诉，说很多考生用起来卡顿，甚至把没填上志愿的责任归到系统上。

甲方明确要求，如果这年再出现这种情况，公司在该省的所有项目将面临被替换的风险。

讨论来讨论去，最后公司将任务落到我们头上时，已经是几个月后的事了，到临危受命阶段，剩下不到半年时间。

虽然直属领导让我们不要有心理负担，做好了表扬，做不好锅也不是我们的，但明显感觉到得到他的压力，毕竟一个不小心就能上新闻。

分析

既然开始做了，再说那些有的没的就没用了，直接开始分析需求。

首先，业务逻辑并不算复杂，难点是在并发和数据准确性上。与客户沟通后，大致了解了并发要求后，于是梳理了下。

方案研讨

接下来我会从当时我们切入问题的点开始，从前期设计到项目落地整个过程的问题及思考，一步步去展示这个项目如何实现的

首先，我们没有去设计表，没有去设计接口，而是先去测试。测试什么？测试我们需要用到或可能用到的中间件是否满足需求

MySQL

首先是MySQL，单节点MySQL测试它的读和取性能，新建一张user表。

向里面并发插入数据和查询数据，得到的TPS大概在5k，QPS大概在1.2W。

查询的时候是带id查询，索引列的查询不及id查询，差距大概在1k。

insert和update存在细微并发差距，但基本可以忽略，影响更新性能目前最大的问题是索引。

如果表中带索引，将降低1k-1.5k的TPS。

目前结论是，mysql不能达到要求，能不能考虑其他架构，比如mysql主从复制，写和读分开。

测试后，还是放弃，主从复制结构会影响更新，大概下降几百，而且单写的TPS也不能达到要求。

至此结论是，mysql直接上的方案肯定是不可行的

Redis

既然MySQL直接查询和写入不满足要求，自然而然想到加入redis缓存。于是开始测试缓存，也从单节点redis开始测试。

get指令QPS达到了惊人的10w，set指令TPS也有8W，意料之中也惊喜了下，仿佛看到了曙光。

但是，redis容易丢失数据，需要考虑高可用方案

实现方案

既然redis满足要求，那么数据全从redis取，持久化仍然交给mysql，写库的时候先发消息，再异步写入数据库。

最后大体就是redis + rocketMQ + mysql的方案。看上去似乎挺简单，当时我们也这样以为 ，但是实际情况却是，我们过于天真了。

这里主要以最重要也是要求最高的保存志愿信息接口开始攻略

故障恢复

第一个想到的是，这些个节点挂了怎么办？

mysql挂了比较简单，他自己的机制就决定了他即使挂掉，重启后仍能恢复数据，这个可以不考虑。

rocketMQ一般情况下挂掉了可能会丢失数据，经过测试发现，在高并发下，确实存在丢消息的现象。

原因是它为了更加高效，默认采用的是异步落盘的模式，这里为了保证消息的绝对不丢失，修改成同步落盘模式。

然后是最关键的redis，不管哪种模式，redis在高并发下挂掉，都会存在丢失数据的风险。

数据丢失对于这个项目格外致命，优先级甚至高于并发的要求。

于是，问题难点来到了如何保证redis数据正确，讨论过后，决定开启redis事务。

保存接口的流程就变成了以下步骤：

1.redis 开启事务，更新redis数据

2.rocketMQ同步落盘

3.redis 提交事务

4.mysql异步入库

我们来看下这个接口可能存在的问题。

第一步，如果redis开始事务或更新redis数据失败，页面报错，对于数据正确性没有影响

第二步，如果rocketMQ落盘报错，那么就会有两种情况。

情况一，落盘失败，消息发送失败，好像没什么影响，直接报错就可。

情况二，如果发送消息成功，但提示发送失败（无论什么原因），这时候将导致mysql和redis数据的最终不一致。

如何处理？怎么知道是redis的有问题还是mysql的有问题？出现这种情况时，如果考生不继续操作，那么这条错误的数据必定无法被更新正确。

考虑到这个问题，我们决定引入一个时间戳字段，同时启动一个定时任务，比较mysql和redis不一致的情况，并自主修复数据。

首先，redis中记录时间戳，同时在消息中也带上这个时间戳并在入库时记录到表中。

然后，定时任务30分钟执行一次，比较redis中的时间戳是否小于mysql，如果小于，便更新redis中数据。如果大于，则不做处理。

同时，这里再做一层优化，凌晨的时候执行一个定时任务，比较redis中时间戳大于mysql中的时间戳，连续两天这条数据都存在且没有更新操作，将提示给我们手动运维。

然后是第三步，消息提交成功但是redis事务提交失败，和第二步处理结果一致，将被第二个定时任务处理。

这样看下来，即使redis崩掉，也不会丢失数据。

第一轮压测

接口实现后，当时怀着期待，信息满满的去做了压测，结果也是当头棒喝。

首先，数据准确性确实没有问题，不管突然kill掉哪个环节，都能保证数据最终一致性。

但是，TPS却只有4k不到的样子，难道是节点少了？

于是多加了几个节点，但是仍然没有什么起色。问题还是想简单了。

重新分析

经过这次压测，之后一个关键的问题被提了出来，影响接口TPS的到底是什么？？？

一番讨论过后，第一个结论是：一个接口的响应时间，取决于它最慢的响应时间累加，我们需要知道，这个接口到底慢在哪一步或哪几步？

于是用arthas看了看到底慢在哪里？

结果却是，最慢的竟然是redis修改数据这一步！这和测试的时候完全不一样。于是针对这一步，我们又继续深入探讨。

结论是：

redis本身是一个很优秀的中间件，并发也确实可以，选型时的测试没有问题。

问题出在IO上，我们是将考生的信息用json字符串存储到redis中的（为什么不保存成其他数据结构，因为我们提前测试过几种可用的数据结构，发现redis保存json字符串这种性能是最高的），

而考生数据虽然单条大小不算大，但是在高并发下的上行带宽却是被打满的。

于是针对这种情况，我们在保存到redis前，用gzip压缩字符串后保存到redis中。

为什么使用gzip压缩方式，因为我们的志愿信息是一个数组，很多重复的数据其实都是字段名称，gzip和其他几个压缩算法比较后，综合考虑到压缩率和性能，在当时选择了这种压缩算法。

针对超过限制的字符串，我们同时会将其拆封成多个（实际没有超过三个的）key存储。

继续压测

又一轮压测下来，效果很不错，TPS从4k来到了8k。不错不错，但是远远不够啊，目标2W，还没到它的一半。

节点不够？加了几个节点，有效果，但不多，最终过不了1W。

继续深入分析，它慢在哪？最后发现卡在了rocketMQ同步落盘上。

同步落盘效率太低？于是压测一波发现，确实如此。

因为同步落盘无论怎么走，都会卡在rocketMQ写磁盘的地方，而且因为前面已经对字符串压缩，也没有带宽问题。

问题到这突然停滞，不知道怎么处理rocketMQ这个点。

同时，另一个同事在测试查询接口时也带来了噩耗，查询接口在1W2左右的地方就上不去了，原因还是卡在带宽上，即使压缩了字符串，带宽仍被打满。

怎么办？考虑许久，最后决定采用较常规的处理方式，那就是数据分区，既然单个rocketMQ服务性能不达标，那么就水平扩展，多增加几个rocketMQ。

不同考生访问的MQ不一样，同时redis也可以数据分区，幸运的是正好redis有哈希槽的架构支持这种方式。

而剩下的问题就是如何解决考生分区的方式，开始考虑的是根据id进行求余的分区，但后来发现这种分区方式数据分布及其不均匀。

后来稍作改变，根据正件号后几位取余分区，数据分布才较为均匀。有了大体解决思路，一顿操作后继续开始压测。

一点小意外

压测之后，结果再次不如人意，TPS和QPS双双不增反降，继续通过arthas排查。

最后发现，redis哈希槽访问时会在主节点先计算key的槽位，而后再将请求转到对应的节点上访问，这个计算过程竟然让性能下降了20%-30%。

于是重新修改代码，在java内存中先计算出哈希槽位，再直接访问对应槽位的redis。如此重新压测，QPS达到了惊人的2W，TPS也有1W2左右。

不错不错，但是也只到了2W，在想上去，又有了瓶颈。

不过这次有了不少经验，马上便发现了问题所在，问题来到了nginx，仍然是一样的问题，带宽！

既然知道原因，解决起来也比较方便，我们将唯一有大带宽的物理机上放上两个节点nginx，通过vip代理出去，访问时会根据考生分区信息访问不同的地址。

压测

已经记不清第几轮压测了，不过这次的结果还算满意，主要查询接口QPS已经来到了惊人的4W，甚至个别接口来到6W甚至更高。

胜利已经在眼前，唯一的问题是，TPS上去不了，最高1W4就跑不动了。

什么原因呢？查了每台redis主要性能指标，发现并没有达到redis的性能瓶颈（上行带宽在65%，cpu使用率也只有50%左右）。

MQ呢？MQ也是一样的情况，那出问题的大概率就是java服务了。分析一波后发现，cpu基本跑到了100%，原来每个节点的最大链接数基本占满，但带宽竟然还有剩余。

静下心来继续深入探讨，连接数为什么会满了？原因是当时使用的SpringBoot的内置容器tomcat，无论如何配置，最大连接数最大同时也就支持1k多点。

那么很简单的公式就能出来，如果一次请求的响应时间在100ms，那么1000 * 1000 / 100 = 10000。

也就是说单节点最大支持的并发也就1W，而现在我们保存的接口响应时间却有300ms，那么最大并发也就是3k多，目前4个分区，看来1W4这个TPS也好像找到了出处了。

接下来就是优化接口响应时间的环节，基本是一步一步走，把能优化的都优化了一遍，最后总算把响应时间控制在了100ms以内。

那么照理来说，现在的TPS应该会来到惊人的4W才对。

再再次压测

怀着忐忑又激动的心情，再一次进入压测环节，于是，TPS竟然来到了惊人的2W5。

当时真心激动了一把，但是冷静之后却也奇怪，按正常逻辑，这里的TPS应该能达到3W6才对。

为了找到哪里还有未发现的坑（怕上线后来惊喜），我们又进一步做了分析，最后在日志上找到了些许端倪。

个别请求在链接redis时报了链接超时，存在0.01%的接口响应时间高于平均值。

于是我们将目光投向了redis连接数上，继续一轮监控，最终在业务实现上找到了答案。

一次保存志愿的接口需要执行5次redis操作，分别是获取锁、获取考生信息、获取志愿信息、修改志愿信息、删除锁，同时还有redis的事务。

而与之相比，查询接口只处理了两次操作，所以对于一次保存志愿的操作来看，单节点的redis最多支持6k多的并发。

为了验证这个观点，我们尝试将redis事务和加锁操作去掉，做对照组压测，发现并发确实如预期的一样有所提升（其实还担心一点，就是抢锁超时）。

准备收工

至此，好像项目的高并发需求都已完成，其他的就是完善完善细节即可。

于是又又又一次迎来了压测，这一次不负众望，重要的两个接口均达到了预期。

这之后便开始真正进入业务实现环节，待整个功能完成，在历时一个半月带两周的加班后，终于迎来了提测。

提测后的问题

功能提测后，第一个问题又又又出现在了redis，当高并发下突然kill掉redis其中一个节点。

因为用的是哈希槽的方式，如果挂掉一个节点，在恢复时重新算槽将非常麻烦且效率很低，如果不恢复，那么将严重影响并发。

于是经过讨论之后，决定将redis也进行手动分区，分区逻辑与MQ的一致。

但是如此做，对管理端就带来了一定影响，因为管理端是列表查询，所以管理端获取数据需要从多个节点的redis中同时获取。

于是管理端单独写了一套获取数据分区的调度逻辑。

第二个问题是管理端接口的性能问题，虽然管理端的要求没考生端高，但扛不住他是分页啊，一次查10个，而且还需要拼接各种数据。

不过有了前面的经验，很快就知道问题出在了哪里，关键还是redis的连接数上，为了降低链接数，这里采用了pipeline拼接多个指令。

上线

一切准备就绪后，就准备开始上线。说一下应用布置情况，8+4+1+2个节点的java服务，其中8个节点考生端，4个管理端，1个定时任务，2个消费者服务。

3个ng，4个考生端，1个管理端。

4个RocketMQ。

4个redis。

2个mysql服务，一主一从，一个定时任务服务。

1个ES服务。

最后顺利上线，虽然发生了个别线上问题，但总体有惊无险，

而真是反馈的并发数也远没有到达我们的系统极限，开始准备的水平扩展方案也没有用上，无数次预演过各个节点的宕机和增加分区，一般在10分钟内恢复系统，不过好在没有排上用场。

最后

整个项目做下来感觉越来越偏离面试中的高并发模式，说实在的也是无赖之举，

偏离的主要原因我认为是项目对数据准确性的要求更高，同时需要完成高并发的要求。

但是经过这个项目的洗礼，在其中也收获颇丰，懂得了去监控服务性能指标，然后也加深了中间件和各种技术的理解。

做完之后虽然累，但也很开心，毕竟在有限的资源下去分析性能瓶颈并完成项目要求后，还是挺有成就感的。

再说点题外话，虽然项目成功挽回了公司在该省的形象，也受到了总公司和领导表扬，但最后也就这样了，

实质性的东西一点没有，这也是我离开这家公司的主要原由。不过事后回想，这段经历确实让人难忘，也给我后来的工作带来了很大的帮助。

从以前的crud，变得能去解决接口性能问题。这之前一遇上，可能两眼茫然或是碰运气，现在慢慢的会根据蛛丝马迹去探究优化方案。

不知道我在这个项目的经历是否能引起大家共鸣？希望这篇文章能对你有所帮助。

概述

几乎所有的系统都会面临安全认证相关的问题，但是安全相关的问题是一个很麻烦的事情。因为它不产生直接的业务价值，而且处理起来复杂繁琐，所以很多时都容易被忽视。很多后期造成重大的安全隐患，往往都是前期的不重视造成的。但庆幸的是安全问题是普遍存在的，而且大家面临的问题几乎相同，所以可以制定行业标准来规范处理，甚至是可以抽出专门的基础设施（例如：AD、LDAP 等）来专门解决这类共性的问题。总之，关于安全问题非常复杂而且麻烦，对于大多数 99% 的系统来说，不要想着在安全问题领域上搞发明和创新，容易踩坑。而且行业的标准解决方案已经非常成熟了。经过长时间的检验。所以在安全领域，踏踏实实的遵循规范和标准就是最好的安全设计。

HTTP 认证

HTTP 认证协议的最初是在 HTTP/1.1标准中定义的，后续由 IETF 在 RFC 7235 中进行完善。HTTP 协议的主要涉及两种的认证机制。

基本认证

常见的叫法是 HTTP Basic，是一种对于安全性不高，以演示为目的的简单的认证机制（例如你家路由器的登录界面），客户端用户名和密码进行 Base64 编码（注意是编码，不是加密）后，放入 HTTP 请求的头中。服务器在接收到请求后，解码这个字段来验证用户的身份。示例：

GET /some-protected-resource HTTP/1.1

Host: example.com

Authorization: Basic dXNlcjpwYXNzd29yZA==

虽然这种方式简单，但并不安全，因为 base64 编码很容易被解码。建议仅在 HTTPS 协议下使用，以确保安全性。

摘要认证

主要是为了解决 HTTP Basic 的安全问题，但是相对也更复杂一些，摘要认证使用 MD5 哈希函数对用户的密码进行加密，并结合一些盐值（可选）生成一个摘要值，然后将这个值放入请求头中。即使在传输过程中被截获，攻击者也无法直接从摘要中还原出用户的密码。示例：

GET /dir/index.html HTTP/1.1

Host: example.com

Authorization: Digest username="user", realm="example.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

**补充：**另在 RFC 7235 规范中还定义当用户没有认证访问服务资源时应返回 401 Unauthorized 状态码，示例：

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Basic realm="Restricted Area"

这一规范目前应用在所有的身份认证流程中，并且沿用至今。

Web 认证

表单认证

虽然 HTTP 有标准的认证协议，但目前实际场景中大多应用都还是基于表单认证实现，具体步骤是：

常见的表单认证页面通常如下：

html>

<html>

<head>

    <title>Login Pagetitle>

head>

<body>

    <h2>Login Formh2>

    <form action="/perform_login" method="post">

        <div class="container">

            <label for="username"><b>Usernameb>label>

            <input type="text" placeholder="Enter Username" name="username" required>

            

            <label for="password"><b>Passwordb>label>

            <input type="password" placeholder="Enter Password" name="password" required>

            

            <button type="submit">Loginbutton>

        div>

    form>

body>

html>