原理

首先，要了解下世界坐标到图像的映射过程，考虑世界坐标点M(Xw,Yw,Zw)映射到图像点m(u,v)的过程，如下图所示：

形式化表示如下：

u,v分别为图像坐标系下的任意坐标点。u0,v0分别为图像的中心坐标。xw,yw,zw表示世界坐标系下的三维坐标点。zc表示相机坐标的z轴值，即目标到相机的距离。R,T分别为外参矩阵的3x3旋转矩阵和3x1平移矩阵。

对外参矩阵的设置：由于世界坐标原点和相机原点是重合的，即没有旋转和平移，所以

相机坐标系和世界坐标系的坐标原点重合，因此相机坐标和世界坐标下的同一个物体具有相同的深度，即zc=zw.于是公式可进一步简化为：

从以上的变换矩阵公式，可以计算得到图像点[u,v]T 到世界坐标点[xw,yw,zw]T的变换公式:

这里Zc是深度值，相机内参为：fx=f/dx, fy= f/dy, cx=u0, cy = v0;

代码实现

1
2
3
4
5
6
7
8
9
10
11

void OBCameraNode::Get_World_Pix_By_Depth(float k[],float scale,int color_x, int color_y, short dep_z, float& world_x, float& world_y, float& world_z) {

    float u=(float)color_x;
    float v=(float)color_y;
    float depthv =dep_z*scale;
    // k[0]:fx k[1]:cx 
    // k[2]:fy k[3]:cy
    world_z = depthv;
    world_x = (u - k[1]) * depthv / k[0];
    world_y = (v - k[3]) * depthv / k[2];
}

ROS2入门篇

架构图

概念简介

客户端库 RCL

RCL（ROS Client Library）ROS客户端库，其实就是ROS的一种API，提供了对ROS话题、服务、参数、Action等接口。

中间件

ROS1的中间件是ROS组织自己基于TCP/UDP机制建立的。

ROS2采用了第三方的DDS作为中间件，将DDS服务接口进行了一层抽象，保证了上层应用层调用接口的统一性。

ROS2为每家DDS供应商都开发了对应的DDS_Interface即DDS接口层，然后通过DDS Abstract抽象层RMW(ROS Middleware Interface)来统一DDS的API。

第一个节点的编写及编译

编写

first_node.cpp

1
2
3
4
5
6
7
8
9
10

#include "rclcpp/rclcpp.hpp"

int main(int argc, char **argv)
{
    // 调用rclcpp的初始化函数
    rclcpp::init(argc, argv);
    // 调用rclcpp的循环运行我们创建的first_node节点
    rclcpp::spin(std::make_shared<rclcpp::Node>("first_node"));
    return 0;
}

CmakLists.txt

1
2
3
4
5
6

cmake_minimum_required(VERSION 3.22)
project(first_node)

find_package(rclcpp REQUIRED)
add_executable(first_node first_ros2_node.cpp)
target_link_libraries(first_node rclcpp::rclcpp)

Cmake

创建一个新的目录build，运行cmake并进行编译

1
2

mkdir build
cd build

运行cmake指令，..代表到上级目录找CMakeLists.txt

1

cmake ..

运行完cmake你应该可以在build目录下看到cmake自动生成的Makefile了，接着就可以运行make指令进行编译

1

make

运行完上面的指令，就可以在build目录下发现first_node节点了

Colcon

只编译一个包

1

colcon build --packages-select YOUR_PKG_NAME 

不编译测试单元

1

colcon build --packages-select YOUR_PKG_NAME  --cmake-args -DBUILD_TESTING=0

运行编译的包的测试

1

colcon test

允许通过更改src下的部分文件来改变install（重要）

每次调整 python 脚本时都不必重新build了

1

colcon build --symlink-install

你可能需要一个梯子翻个墙：点击这里试试小鱼用了很多年的梯子

节点介绍

交互

节点与节点之间就必须要通信了，那他们之间该如何通信呢？ROS2早已为你准备好了一共四种通信方式:

• 话题-topics

• 服务-services

• 动作-Action

• 参数-parameters

  

节点相关的CLI

运行节点(常用)

1

ros2 run <package_name> <executable_name>

查看节点列表(常用)：

1

ros2 node list

查看节点信息(常用)：

1

ros2 node info <node_name>

重映射节点名称

1

ros2 run turtlesim turtlesim_node --ros-args --remap __node:=my_turtle

运行节点时设置参数

1

ros2 run example_parameters_rclcpp parameters_basic --ros-args -p rcl_log_level:=10

一、项目介绍

项目核心信息：简易版抖音后端服务

Github 地址：https://github.com/qiong-14/EasyDouYin

二、项目分工

三、项目实现

3.1 技术选型与相关开发文档

3.1.1 Web开发套件

• Hertz

现有的web开发的HTTP框架大多使用gin框架，而如今越来越多的web服务转向微服务架构，Hertz作为一个字节跳动内部的微服务HTTP框架，在设计之初参考了其他开源框架的优势，并结合字节跳动内部的需求，使其具有高易用性、高性能、高扩展性等特点，对微服务性能有着很好的提升。同时，Hertz支持包括Autotls, Http2等各种扩展，更加利于用户的不同定制化的需求。

• GORM

gorm框架作为golnag语言一款性能极好的ORM库，支持多种数据库。使用起来简单方便，支持链式操作和原生SQL，对开发人员相对友好。另外，现阶段gorm框架有良好的文档和社区支持，非常方便学习和解决问题。基于以上优点，我们选择gorm作为我们的ORM框架。

3.1.2 数据库选型

关系型数据库是基于关系模型的数据库，它使用二维表来存储结构化的数据。关系型数据库适合存储需要做结构化查询、事务性、一致性的数据，比如用户的账号、地址等。剩余的数据，比如非结构化或半结构化的数据，比如图片、视频、文档等，不能存在关系型中，因为它们不适合用二维表来表示和查询。这些数据可以使用非关系型数据库来存储，比如HBase、Cassandra、Redis等。在本项目中，有关用户关系、视频信息（不包括视频文件本身）的内容都可以用关系型数据库来储存，而视频文件就需要文件系统辅助存储。因此我们选用Mysql来存储用户信息、视频信息、用户视频关系、用户关注关系、聊天信息结构化的数据，并用Redis对部分数据进行缓存。

3.1.3 对象存储服务的应用

视频的元信息需要持久化存储到关系型数据库, 包括视频的标题、封面、所有者、视频的标签以及当前的状态(待审核、已审核待上线、待修改、已删除)。

视频的封面和视频本身属于超大的不定规模的二进制数据, 可以存到文件系统中, 以FTP或基于FTP的方式向外访问, 但这种方式有很多弊端, 比如视频链接可能会长期有效, 给服务器造成很大负担, 如果视频被删除, 需要同步删除视频本身以避免视频泄露, 以及潜在的FTP安全漏洞.

基于以上考量, 这样的二进制数据存储到对象存储服务, 如MinIO中. 经过了解, Minio可以产生仅在一段时间内有效的URL传递到前端. MinIO官方也有Go的SDK方便开发者使用.

3.1.4 Redis对MySQL慢查询的补充

3.2 架构设计

3.3 项目代码介绍

3.4 数据库表设计

以上为数据库表的关系图，根据功能设计我们设计了六张表，红色为主表，其他表基于这两张表来拓展功能：

3.5 用户名验证和密码强度评估

对于用户注册时输入的用户名和密码我们可以在后端进行进行验证，如果用户名不符合特定格式不允许用户进行注册（本项目使用的是邮箱格式，只有符合邮箱格式的用户名才能通过注册），以及对于密码强度较弱的用户拒绝注册。采用正则表达式匹配用户名和密码字符串实现以上功能。

四、测试结果

通过demo的测试函数进行功能测试：

五、项目总结与反思

1. 目前仍存在的问题
2. 已识别出的优化项
3. 架构演进的可能性
4. 项目过程中的反思与总结

从刚开始的完全不了解go语言到项目的完成，我们组遇到过不少的困难，但是最终还是坚持完成了项目。总结来说，本项目完整的实现所有的服务功能，由于时间和阅历的问题，项目也存在些许不足之处：

1. 微服务架构方面，采用了Hertz架构为以后扩展微服务进行了准备，当前业务还是耦合性较强，不利于业务细化。
2. 对于高并发场景：数据库方面只使用了redis缓存进行优化，没有进行分库分表，分区操作，读写分离等，服务器方面没有采用消息队列，负载均衡等方法

Redis介绍

简单概念

• redis作为NoSql的一种，拥有NoSQL相关特点

• redis支持数据的持久化，将内存中的数据保存到磁盘中，重启的时候可以再次加载进行使用

• redis不仅仅支持key-value数据，还支持：string,list,set,hash等

• redis支持数据备份，即master-slaver模式的数据备份

常见命令

通用指令是部分数据类型的，都可以使用的指令，常见的有:

• KEYS:查看符合模板的所有key，不建议在生产环境设备上使用
• DEL:删除一个指定的key
• EXISTS:判断key是否存在
• EXPIRE:给一个key设置有效期，有效期到期时该key会被自动删除
• TTL:查看一个KEY的剩余有效期 (-1：代表永久有效)

还有其他几种数据结构操作命令参考Redis官网

go操作Redis

获取Redis连接

1
2
3
4
5
6
7
8
9
10

func GetRedisConnection() redis.Conn {
    c, err := redis.Dial("tcp", "localhost:6379")
    if err != nil {
        fmt.Println("conn redis failed,", err)
        return nil
    }
    fmt.Println("redis conn success")

    return c
}

Dial获取Redis连接：本地Redis使用6379端口

操作基础命令

• Set命令

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

//获取redis连接
    conn := utils.GetRedisConnection()
    if conn == nil {
        fmt.Println("获取redis连接失败")
    }

    //将token存入用户信息存入redis中
    token := utils.RandString(32)
    userJson, err := json.Marshal(user)
    if err != nil {
        fmt.Println(err)
    }
//使用set命令
    conn.Do("set", constant.USER_FLAG+token, userJson)

• Get命令

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

conn := utils.GetRedisConnection()
    userjson, err := redis.String(conn.Do("get", constant.USER_FLAG+token))
    if err != nil {
        fmt.Println(err)
    }

    var user common.User
    json.Unmarshal([]byte(userjson), &user)
    //redis中不存在用户信息，从数据库中查找
    if user.Username == "" {
        user = dao.GetInfos(userId)
    }

注：redis.string()方法将get命令返回的数据转成字符串，还有类似的redis.int()方法

基本思路

每个用户有都有一个关注 set 和粉丝 set，set 的存储的是用户的唯一 ID。

每当用户关注某人时，就会被写入到关注 set 中，同时对方的粉丝 set 也会记录当前用户

当需要判断两人是否进行互相关注时，可以直接使用 redis 中的 集合操作，找出对方关注 set 的交集。

原本我们使用 SQL 来实现这个功能的，性能上并不是很高效。

这样就可以免去使用 MySQL 查询实现了，更高效地提高性能。

操作Set相关命令

在上述操作Redis基础命令上，我们进阶一下使用最常用的set数据结构命令

• 判断用户是否是成员

1
2
3
4
5
6
7
8

//省略Redis连接
//redis中set判断是否存在
        result, err := redis.Int(conn.Do("SISMEMBER", constant.VIDEO_FLAG+string(videoId), user.UserId))
        //不存在，点赞操作
        if err != nil {
            fmt.Println(err)
        }
复制代码

当result==1时:表示是存在该成员变量

当result==0时:表示是不存在该成员变量

• 获取所有成员

1
2

conn.Do("SMEMBERS", constant.VIDEO_FLAG+string(videoId))
复制代码

返回SET集合该key的所有成员

注意点

使用 redis 作为缓存需要额外注意“缓存失效”的情况。当 redis 查不到数据时，需要转而查询 MySQL 后端数据库，并且查到数据后，一定要将其更新到 redis 服务器中！

这里有一个提升效率的小细节：在往 redis 服务器更新数据的时候，可以作异步处理，另开一个协程进行更新。

这样当从 MySQL 查询出数据后，不必等待 redis 服务器的更新就可以及时将数据响应了！

消息队列

消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ

消息队列是什么

• 解耦

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功

库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作

假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦

• 削峰

流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛。

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

a、可以控制活动的人数

b、可以缓解短时间内高流量压垮应用

用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。

秒杀业务根据消息队列中的请求信息，再做后续处理

• 异步

按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。

• 日志处理

日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。架构简化如下

日志采集客户端，负责日志数据采集，定时写受写入Kafka队列

Kafka消息队列，负责日志数据的接收，存储和转发

日志处理应用：订阅并消费kafka队列中的日志数据

消息队列的前世今生

消息队列-Kafka

kafka使用场景，业务日志、用户行为数据、Metrics数据

基本概念，Producer、Cluster、Consumer、Topic、Partition

数据迁移、Offset、Partition选主

一条消息从生产到消费是如何处理的，Producer端逻辑、Broker端逻辑、Consumer端逻辑

消息队列-BMQ

Kafka在使用中遇到问题

BMQ架构

BMQ各模块是如何工作的，Broker、Proxy、HDFS、MetaStorage

BMQ多机房容灾

RPC 原理与实践

RPC 的基本概念

RPC（Remote Procedure Call Protocol）远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

• Client：RPC协议的调用方。就像上文所描述的那样，最理想的情况是RPC Client在完全不知道有RPC框架存在的情况下发起对远程服务的调用。但实际情况来说Client或多或少的都需要指定RPC框架的一些细节。
• Server：在RPC规范中，这个Server并不是提供RPC服务器IP、端口监听的模块。而是远程服务方法的具体实现（在JAVA中就是RPC服务接口的具体实现）。其中的代码是最普通的和业务相关的代码，甚至其接口实现类本身都不知道将被某一个RPC远程客户端调用。
• Stub/Proxy：RPC代理存在于客户端，因为要实现客户端对RPC框架“透明”调用，那么客户端不可能自行去管理消息格式、不可能自己去管理网络传输协议，也不可能自己去判断调用过程是否有异常。这一切工作在客户端都是交给RPC框架中的“代理”层来处理的。
• Message Protocol：在上文我们已经说到，一次完整的client-server的交互肯定是携带某种两端都能识别的，共同约定的消息格式。RPC的消息管理层专门对网络传输所承载的消息信息进行编号和解码操作。目前流行的技术趋势是不同的RPC实现，为了加强自身框架的效率都有一套（或者几套）私有的消息格式。例如前文所讲到的RMI框架使用的消息协议为JRMP；后文我们将详细讲解的RPC框架Thrift也有私有的消息协议，“- Transfer/Network Protocol”（当然它还支持一些通用的消息格式，如JSON）。
• Transfer/Network Protocol：传输协议层负责管理RPC框架所使用的网络协议、网络IO模型。例如Hessian的传输协议基于HTTP（应用层协议）；而Thrift的传输协议基于TCP（传输层协议）。传输层还需要统一RPC客户端和RPC服务端所使用的IO模型；
• Selector/Processor：存在于RPC服务端，由于服务器端某一个RPC接口的实现的特性（它并不知道自己是一个将要被RPC提供给第三方系统调用的服务）。所以在RPC框架中应该有一种“负责执行RPC接口实现”的角色。它负责了包括：管理RPC接口的注册、判断客户端的请求权限、控制接口实现类的执行在内的各种工作。
• IDL：实际上IDL（接口定义语言）并不是RPC实现中所必须的。但是需要跨语言的RPC框架一定会有IDL部分的存在。这是因为要找到一个各种语言能够理解的消息结构、接口定义的描述形式。如果您的RPC实现没有考虑跨语言性，那么IDL部分就不需要包括，例如JAVA RMI因为就是为了在JAVA语言间进行使用，所以JAVA RMI就没有相应的IDL。

RPC 框架分层设计

编解码层

• 数据格式

  • 语言特定格式：例如 java.io.Serializable
  • 文本格式：例如 JSON、XML、CSV 等
  • 二进制编码：常见有 Thrift 的 BinaryProtocol，Protobuf，实现可以有多种形式，例如 TLV 编码 和 Varint 编码

• 选型考察点

  • 兼容性
  • 通用型
  • 性能
  • 空间开销
  • 时间开销

• 生成代码和编解码层相互依赖，框架的编解码应当具备扩展任意编解码协议的能力

协议层

• 以 Thrift 的 THeader 协议为例

• 协议解析

网络通信层

• 阻塞 IO 下，耗费一个线程去阻塞在 read(fd) 去等待用足够多的数据可读并返回。

• 非阻塞 IO 下，不停对所有 fds 轮询 read(fd) ，如果读取到 n <= 0 则下一个循环继续轮询。

第一种方式浪费线程（会占用内存和上下文切换开销），第二种方式浪费 CPU 做大量无效工作。而基于 IO 多路复用系统调用实现的 Poll 的意义在于将可读/可写状态通知和实际文件操作分开，并支持多个文件描述符通过一个系统调用监听以提升性能。 网络库的核心功能就是去同时监听大量的文件描述符的状态变化(通过操作系统调用)，并对于不同状态变更，高效，安全地进行对应的文件操作。

配置

参数

介绍

Key

用于设置签名密钥（必要配置）

KeyFunc

用于设置获取签名密钥的回调函数，设置后 token 解析时将从 KeyFunc 获取 jwt 签名密钥

Timeout

用于设置 token 过期时间，默认为一小时

MaxRefresh

用于设置最大 token 刷新时间，允许客户端在 TokenTime + MaxRefresh 内刷新 token 的有效时间，追加一个 Timeout 的时长

Authenticator

用于设置登录时认证用户信息的函数（必要配置）

Authorizator

用于设置授权已认证的用户路由访问权限的函数

PayloadFunc

用于设置登陆成功后为向 token 中添加自定义负载信息的函数

Unauthorized

用于设置 jwt 验证流程失败的响应函数

流程

用户登陆（认证）

注册完成后，服务器需要在用户第一次登陆的时候，验证用户账号和密码，并签发 jwt token。

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

JwtMiddleware, err = jwt.New(&jwt.HertzJWTMiddleware{
    Key:           []byte("secret key"),
    Timeout:       time.Hour,
    MaxRefresh:    time.Hour,
    Authenticator: func(ctx context.Context, c *app.RequestContext) (interface{}, error) {
        var loginStruct struct {
            Account  string `form:"account" json:"account" query:"account" vd:"(len($) > 0 && len($) < 30); msg:'Illegal format'"`
            Password string `form:"password" json:"password" query:"password" vd:"(len($) > 0 && len($) < 30); msg:'Illegal format'"`
        }
        if err := c.BindAndValidate(&loginStruct); err != nil {
            return nil, err
        }
        users, err := mysql.CheckUser(loginStruct.Account, utils2.MD5(loginStruct.Password))
        if err != nil {
            return nil, err
        }
        if len(users) == 0 {
            return nil, errors.New("user already exists or wrong password")
        }

        return users[0], nil
    },
    PayloadFunc: func(data interface{}) jwt.MapClaims {
        if v, ok := data.(*model.User); ok {
            return jwt.MapClaims{
                jwt.IdentityKey: v,
            }
        }
        return jwt.MapClaims{}
    },
})

• Authenticator：用于设置登录时认证用户信息的函数，demo 当中定义了一个 loginStruct 结构接收用户登陆信息，并进行认证有效性。这个函数的返回值 users[0] 将为后续生成 jwt token 提供 payload 数据源。

• PayloadFunc：它的入参就是 Authenticator 的返回值，此时负责解析 users[0]，并将用户名注入 token 的 payload 部分。

• Key：指定了用于加密 jwt token 的密钥为 "secret key"。

• Timeout：指定了 token 有效期为一个小时。

• MaxRefresh：用于设置最大 token 刷新时间，允许客户端在 TokenTime + MaxRefresh 内刷新 token 的有效时间，追加一个 Timeout 的时长。

Token 的返回

1
2
3
4
5
6
7
8
9
10

JwtMiddleware, err = jwt.New(&jwt.HertzJWTMiddleware{
    LoginResponse: func(ctx context.Context, c *app.RequestContext, code int, token string, expire time.Time) {
        c.JSON(http.StatusOK, utils.H{
            "code":    code,
            "token":   token,
            "expire":  expire.Format(time.RFC3339),
            "message": "success",
        })
    },
})

• LoginResponse：在登陆成功之后，jwt token 信息会随响应返回，你可以自定义这部分的具体内容，但注意不要改动函数签名，因为它与 LoginHandler 是强绑定的。

Token 的校验

访问配置了 jwt 中间件的路由时，会经过 jwt token 的校验流程。

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

JwtMiddleware, err = jwt.New(&jwt.HertzJWTMiddleware{
    TokenLookup:   "header: Authorization, query: token, cookie: jwt",
    TokenHeadName: "Bearer",
    HTTPStatusMessageFunc: func(e error, ctx context.Context, c *app.RequestContext) string {
        hlog.CtxErrorf(ctx, "jwt biz err = %+v", e.Error())
        return e.Error()
    },
    Unauthorized: func(ctx context.Context, c *app.RequestContext, code int, message string) {
        c.JSON(http.StatusOK, utils.H{
            "code":    code,
            "message": message,
        })
    },
})

• TokenLookup：用于设置 token 的获取源，可以选择 header、query、cookie、param，默认为 header:Authorization，同时存在是以左侧一个读取到的优先。当前 demo 将以 header 为数据源，因此在访问 /ping 接口时，需要你将 token 信息存放在 HTTP Header 当中。

• TokenHeadName：用于设置从 header 中获取 token 时的前缀，默认为 "Bearer"。

• HTTPStatusMessageFunc：用于设置 jwt 校验流程发生错误时响应所包含的错误信息，你可以自行包装这些内容。

• Unauthorized：用于设置 jwt 验证流程失败的响应函数，当前 demo 返回了错误码和错误信息。

用户信息的提取

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

JwtMiddleware, err = jwt.New(&jwt.HertzJWTMiddleware{
    IdentityKey: IdentityKey,
    IdentityHandler: func(ctx context.Context, c *app.RequestContext) interface{} {
        claims := jwt.ExtractClaims(ctx, c)
        return &model.User{
            UserName: claims[IdentityKey].(string),
        }
    },
})

// Ping .
func Ping(ctx context.Context, c *app.RequestContext) {
    user, _ := c.Get(mw.IdentityKey)
    c.JSON(200, utils.H{
        "message": fmt.Sprintf("username:%v", user.(*model.User).UserName),
    })
}

• IdentityHandler：用于设置获取身份信息的函数，在 demo 中，此处提取 token 的负载，并配合 IdentityKey 将用户名存入上下文信息。
• IdentityKey：用于设置检索身份的键，默认为 "identity"。
• Ping：构造响应结果，从上下文信息中取出用户名信息并返回。

参数绑定

hertz 使用开源库 go-tagexpr 进行参数的绑定及验证，demo 中也频繁使用了这个特性。

1
2
3
4
5
6
7
8

var loginStruct struct {
    // 通过声明 tag 进行参数绑定和验证
    Account  string `form:"account" json:"account" query:"account" vd:"(len($) > 0 && len($) < 30); msg:'Illegal format'"`
    Password string `form:"password" json:"password" query:"password" vd:"(len($) > 0 && len($) < 30); msg:'Illegal format'"`
}
if err := c.BindAndValidate(&loginStruct); err != nil {
    return nil, err
}

基本git命令

查看仓库名

git remote

查看推送至仓库的用户名和邮箱

git config user.name git config user.email

设置推送至仓库的用户名和邮箱

git config –global user.email “you@example.com“

git config –global user.name “Your Name”

–global 对当前用户所有仓库有效

–local 只对某个仓库有效

–system 对系统所有登录的用户有效

显示config配置

git config –list

刷新远程仓库分支

git fetch

查看仓库名对应的远程仓库的地址

git remote -v

git远程仓库更换名称

git remote set-url origin 新的远程仓库地址

上传到远程仓库命令：

git push 仓库名 分支名

//默认是：git push origin master

显示上一次提交之前工作目录与git仓库之间的差异

git diff HEAD^

// 在git pull后，可以通过git diff HEAD^ 来查看拉下来的文件有那些具体的修改。

git撤销本次pull

git merge –abort

// 如果不小心pull了代码，并且有冲突，不想解决。想要放弃本次pull就使用这个命令。

查看所有分支的所有操作记录

git reflog

合并到当前所在分支

如：git merge winne

// 把本地winne分支代码合并到当前master分支

如：git pull origin winne

// 把远程仓库winne分支代码合并到当前master分支

团队开发clone项目和提交项目

为了让同组开发人员也能把github上的资源下载下来之后，他修改的版本也能够同步到远程仓库中，那么就要在这个仓库上添加合伙人（collaborator）： 此步骤是在github上操作，找到 collaborator的设置地方，然后填好合伙人的用户名设置好，然后点击添加。之后他就会收到一个邀请信息，通过之后就能一同同步更新这个开发项目了。 git status :查看当前状态下的文件变化

1. 组员要把项目先克隆下来：git clone 地址
2. 安装需要的依赖项，运行项目，参与项目开发: npm install
3. 新建并切换到新分支（因为人多了不可能都在主分支master开发）：

多人协作解决代码上的冲突问题

在多人协作的时候，每次进行版本的push都要先同步一下自己本地项目和远程仓库上的最新版本代码，避免出现代码冲突问题。

使用 git pull origin 分支名 （把想要的分支内容拉取到本地）

1. 拉取github仓库代码同步合并到本地文件：git pull origin 分支名
2. 然后直接到本地文件中进行合并代码后的冲突代码的取舍（编辑器工具有智能提示，所以很容易进行对比，手动解决冲突）
3. 最后就可以把完好的没有冲突的代码提交同步到github了
4. 本地开发代码关联新创建的远程仓库

一、前言

• 业务流程

  • 定时扫描抖音用户集卡状态
  • 汇总计算用户的瓜分金额
  • 定时开奖

• 技术体量

  • 亿级用户规模
  • 十亿级资金规模
  • 百万级读写QPS

• 方案引出

  • 自动化 + 定时执行 + 海量数据 + 高效稳定 = 分布式定时任务

二、发展历程

发展历史

• Windows批处理

• Windows任务计划程序

• Linux命令-CronJob

• 单机定时任务-Timer、Ticker

• 单机定时任务-ScheduledExecutorService

• 任务调度- Quartz

• 分布式定时任务

分布式定时任务

定义

• 定时任务是指系统为了自动完成特定任务，实时、延时、周期性完成任务调度的过程。
• 分布式定时任务是把分散的、可靠性差的定时任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式。

特点

• 自动化、平台化、分布式、伸缩性、高可用

• 执行方式

  • 单机任务
  • 广播任务
  • Map任务
  • MapReduce任务

发奖金额计算：MapReduce 定时开奖：Map

业内定时任务框架

• 大众点评Xxl-job

  Xxl-job很大一个优势在于开源且免费，并且轻量级，开箱即用，操作简易，上手快，企业维护起来成本不高，因而在中小型公司使用非常广泛。

• 阿里巴巴SchedulerX

  分布式任务调度SchedulerX2.0是阿里巴巴基于Akka架构自研的新一代分布式任务调度平台，提供定时调度、调度任务编排和分布式批量处理等功能。 SchedulerX可在阿里云付费使用。它功能非常强大，在阿里巴巴内部广泛使用并久经考验。

• 腾讯TCT

  仅在内部使用，未开源、未商用

三、实现原理

整体架构

• 核心架构

• 数据流

.png)

• 功能架构

控制台Admin

• 任务：Job，任务元数据
• 任务实例：JobInstance,周期任务会生 成多个任务实例
• 任务结果：JobResult,任务实例运行的 结果
• 任务历史：JobHistory,用户可以修改任 务信息，任务实例对应的任务元数据可 以不同，因而使用任务历史存储

触发器Trigger

• 定期扫描+ 延时消息（腾讯、字节方案）

• 时间轮（Quartz方案）

  时间轮是一种高效利用线程资源进行批量化调度的一种调度模型。时间轮是一个存储环形队列，底层采用数组实现，数组中的每个元素可以存放一个定时任务列表。

• 高可用
  • 存储：不同国别、业务做资源隔离
  • 运行：不同级别、业务分开执行
  • 部署：采用多机房集群化部署，避免单点故障，通过数据库锁或分布式锁保证只被触发一次

调度器Scheduler

资源来源

• 业务系统
  • 优点：任务执行逻辑与业务系统共用一份资源，利用率更高
  • 缺点：容易发生影响在线服务的事故，不能扩缩容
• 定时任务平台
  • 优点：任务执行逻辑与业务系统相互隔离，优雅地扩缩容
  • 缺点：消耗更多机器资源，需要额外为定时任务平台申请接口调用权限

资源调度

• 节点选择
  • 随机节点执行：选择集群中一个可用的执行节点执行调度任务。适用场景：定时对账。
  • 广播执行：在集群中所有的执行节点分发调度任务并执行。适用场景：批运维。
  • 分片执行：按照用户自定义分片逻辑进行拆分，分发到集群中不同节点并行执行，提升资源利用效率。适用场景：海星日志统计。
• 任务分片
  • 通过任务分片来提高任务执行的效率和资源地利用率
• 故障转移
  • 分片任务基于一致性hash策略分发任务，当某Executor异常时，调度器会将任务分发到其他Executor，任务最终成功

执行器Executor

四、业务应用

所有需要定时、延时、周期性执行任务的业务场景，都可以考虑使用分布式定时任务

• 电商
  • 订单30分钟未付款自动关闭订单
  • 定时给商家、达人发送消品，给·的奖励用户发放优惠券等
• 互动
  • 支付宝集五福
  • 字节吞节集卡瓜分红包
• 游戏
  • 活动估束后批量补发用户未领取
  • 定期更新游戏内榜单

五、课程收获

• 知识面扩充
  • 对分布式定时任务建立起宏观的认知，并深入了解其实现原理
  • 了解关联的单机定时任务、大数据处理引擎，通过了解不同实现方案的优劣来拓展知识面
• 项目实践能力加强
  • 了解在哪些实际业务场景中使用分布式定时任务
  • 对于实际业务场景的中间件选型、技术方案设计做到成竹在胸

青训营 X 码上掘金 攒青豆 Golang

当青训营遇上码上掘金

题目描述

现有 n 个宽度为 1 的柱子，给出 n 个非负整数依次表示柱子的高度，排列后如下图所示，此时均匀从上空向下撒青豆，计算按此排列的柱子能接住多少青豆。（不考虑边角堆积）

1
2
3
4
5

以下为上图例子的解析：

输入：height = [5,0,2,1,4,0,1,0,3]  
输出：17  
解析：上面是由数组 [5,0,2,1,4,0,1,0,3] 表示的柱子高度，在这种情况下，可以接 17 个单位的青豆。

解题思路

本人刷题用c++较多，由于本次青训营学习的语言为Golang，故采用Go来解题。

题目给出n个柱子及对应的高度，由于柱子高低不同，导致我们难以判断两个柱子之间会积攒多少青豆。但是我们如果将柱子简化到高度只有1，那么可以容易得到积攒的青豆数。

我们对上图的例子进行分析。得到第一层height1 = [1,0,1,1,1,0,1,0,1] ，容易得知第一层青豆数为3

之后剩余部分为 height2 = [4,0,1,0,3,0,0,0,2]

如此一来，我们得到了一个新的height2，我们可以通过递归求解，也可以自底向上一层一层求解。我采用了第二种。

层数

青豆数

1

3

2

5

3

6

4

3

5

0

合计

17

代码

为了青豆 - 码上掘金 (juejin.cn)

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

package main

import "fmt"

func main() {
  // example :
  // n:=9
  // height := [...]int{5,0,2,1,4,0,1,0,3}
  var n int
  fmt.Scanf("%d", &n)
  height:=make([]int,1000)
  for i:= 0; i < n; i++ {
    fmt.Scanf("%d", &height[i])
  }
  sum:=0
  flag:=1
  for flag==1{
    flag=0
    count:=0
    for i := 0; i < n; i++ {
      if height[i]>0{
        if flag==0{
          flag=1
          height[i]--
        }else{
          height[i]--
          sum+=count
          count=0
        }
      }else if height[i]<=0 && flag==1{
        count++
      }
    }
  }
  fmt.Printf("青豆数:%d",sum)
}

编码注意事项

• 每一层的豆子需要由两边的柱子挡住，如果柱子数为0或1，青豆数为0，我采用flag来进行标记，flag初始为0，找到第一个柱子时flag=1，并开始计数。
• 外层循环停止条件，当遍历完数组后，flag仍为0，则表明最高层的青豆数已经计算完毕，退出循环。
• 我是从横向的角度分析青豆数，也可以从纵向的角度分析，每个柱子上方的青豆数与左侧最高柱子高度和右侧最高柱子高度中的最小值有关。

一、概述

企业的信息安全体系是非常庞大的，任何一个环节都可能会出现安全风险。其中，黑灰产是安全人员最为关注的一个风险来源，也是历年来导致企业和用户损失最大的因素。

如果某个平台或者业务被黑灰产盯上，可能是因为这个业务存在安全隐患被黑灰产利用，也可能只是被黑灰产当做牟利的垫脚石。对黑灰产的监控和防御，就是要了解他们的意图、手段和行为模式，避免被黑灰产攻击或者利用。

本次可能会给大家简单介绍国内黑灰产的情况，挑选了几种比较经典的黑产作弊手段进行详细分析，希望能帮助大家对黑灰产这个群体有一定的了解，提升各位的安全意识，在日后的工作和生活中，多一些安全角度的思考。

二、国内黑产介绍

常见黑产

诈骗、木马、薅羊毛、钓鱼、黄牛、病毒、博彩、拖库、引流、盗号、跑分、勒索软件

发展趋势

规模化

• 借助脚本、软件实现攻击的批量化
• 上游各类资源丰富，大大降低攻击成本，同时攻击成功率也比较高

组织化

• 以工作室形式
• 分工明确、合作紧密
• 某些黑产甚至成立了公司

平台化

• 平台级的爬虫、群控、钓鱼、DDoS攻击工具，攻击成本大大降低且难以追责
• 各类平台将黑产手中零散的资源进行整合

三、常见的黑惨技术分析

• 人脸识别对抗
• 地理位置对抗
• 银行业务逻辑漏洞

四、安全防护体系的建设

事前

• 情报监控
  • 暗网
  • 贴吧
  • TG
  • 破解论坛
• SDLC
• 漏洞扫描

事中

• 渗透测试
• 威胁感知
  • 用户行为异常
  • 接口数据异常
  • 恶意流量检测
• 风控/安全策略

事后

• 威胁建模
• 攻击溯源

其他

• 验证码
• 安全SDK
• 代理检测
• 人脸识别
• 行为审计

五、思考

• 身边是否有一些事情是可能与黑产有关的，如何辨别？
• 当前所学习和研究的技术，是否存在一些公开的安全问题，比如漏洞或者设计缺陷？如何避免他人利用这些问题来攻击你？
• 如果无法避免被攻击，如何将损失降低到最小？