海量数据处理商用短链接生成器平台 - 5

从零开始学习人工智能

于 2024-08-06 20:59:01 发布

阅读量715

点赞数 7

分类专栏： java开发文章标签： oracle 数据库

本文链接：https://blog.csdn.net/weixin_41544125/article/details/140966010

版权

java开发专栏收录该内容

4 篇文章 0 订阅

订阅专栏

第九章账号微服务注册-登录功能开发完善

第1集账号微服务注册功能业务介绍和代码编写

简介：账号微服务注册接口介绍和业务代码编写

微服务注册接口开发
- 请求实体类编写
- controller
- service
  - 手机验证码验证
  - 密码加密（TODO）
  - 账号唯一性检查(TODO)
  - 插入数据库
  - 新注册用户福利发放(TODO)
- mapper
密码存储安全
- 彩虹表暴力破解
  - 网站：https://www.cmd5.com/
  - 密码存储常用方式
    - 双重MD5
    - MD5+加盐
    - 双重MD5+加盐

第2集注册手机号唯一性保证方案和作业-分库分表下的思考

简介：注册手机号唯一性安全保证方案和作业-分库分表下的思考

注册业务
- 同个时刻注册，需要保证注册手机号在数据库里唯一
高并发下问题发现扩大
- 万分之一的时间，放大100万倍
- 不是你的代码安全，而是你的并发量过少，几个几十个并发量发现不了问题
- 几十万几百万并发，线下难模拟
  - 代码暂停思维：假如非原子性代码运行到某一行暂停，其他线程重新操作是否会出问题
  - 时间扩大思维：1纳秒的时间，扩大到1分钟，代码逻辑是否会有问题
  - 类似幂等性处理
Redis：先看redis是否有，然后没的话则是新的注册
- key -value 存储, 配置60秒过期
- 非原子性操作，存在不一致
数据库唯一索引(建表的时间已经添加)

CREATE TABLE `account` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `account_no` bigint DEFAULT NULL,
  `head_img` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '头像',
  `phone` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '手机号',
  `pwd` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '密码',
  `secret` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '盐，用于个人敏感信息处理',
  `mail` varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '邮箱',
  `username` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '用户名',
  `auth` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL COMMENT '认证级别，DEFAULT，REALNAME，ENTERPRISE，访问次数不一样',
  `gmt_create` datetime DEFAULT CURRENT_TIMESTAMP,
  `gmt_modified` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_phone` (`phone`) USING BTREE,
  UNIQUE KEY `uk_account` (`account_no`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

留个作业
- 分库分表下- 手机号唯一性保证怎么做？

在这里插入图片描述

第3集账号微服务开发之登录模块逻辑和解密

简介：账号微服务登录模块开发

核心逻辑
- 通过phone找数据库记录
- 获取盐，和当前传递的密码就行加密后匹配
- 生成token令牌
controller

/**
     * 登录
     * @param loginRequest
     * @return
     */
    @PostMapping("login")
    public JsonData register(@RequestBody UserLoginRequest loginRequest){


        JsonData jsonData = userService.login(loginRequest);
        return jsonData;
    }

service

第4集分布式应用下登录检验解决方案 JWT讲解

简介：分布式应用的登录检验解决方案 JWT讲解 json web token

什么是JWT
- JWT 是一个开放标准，它定义了一种用于简洁，自包含的用于通信双方之间以 JSON 对象的形式安全传递信息的方法。可以使用 HMAC 算法或者是 RSA 的公钥密钥对进行签名
- 简单来说: 就是通过一定规范来生成token，然后可以通过解密算法逆向解密token，这样就可以获取用户信息
```
          {
                id:888,
                name:'小D',
                expire:10000
            }
            
            funtion 加密(object, appsecret){
                xxxx
                return base64( token);
            }


            function 解密(token ,appsecret){


                xxxx
                //成功返回true,失败返回false
            }
```
- 优点
  - 生产的token可以包含基本信息，比如id、用户昵称、头像等信息，避免再次查库
  - 存储在客户端，不占用服务端的内存资源
- 缺点
  - token是经过base64编码，所以可以解码，因此token加密前的对象不应该包含敏感信息，如用户权限，密码等
  - 如果没有服务端存储，则不能做登录失效处理，除非服务端改秘钥
JWT格式组成头部、负载、签名
- header+payload+signature
  - 头部：主要是描述签名算法
  - 负载：主要描述是加密对象的信息，如用户的id等，也可以加些规范里面的东西，如iss签发者，exp 过期时间，sub 面向的用户
  - 签名：主要是把前面两部分进行加密，防止别人拿到token进行base解密后篡改token
关于jwt客户端存储
- 可以存储在cookie，localstorage和sessionStorage里面

第5集登录校验Json Web Token实战之封装通用方法

讲解：引入相关依赖并开发JWT工具类, 开发生产token和校验token的办法

聚合工程加入版本依赖，common项目加入相关依赖

    <!-- JWT相关 -->
    <dependency>
      <groupId>io.jsonwebtoken</groupId>
      <artifactId>jjwt</artifactId>
      <version>0.7.0</version>
    </dependency>

common项目中封装生产token方法

     /**
     * 根据用户信息，生成令牌
     *
     * @param user
     * @return
     */
    public static String geneJsonWebToken(LoginUser user) {


        Long userId = user.getId();
        String token = Jwts.builder().setSubject(SUBJECT)
                .claim("head_img", user.getHeadImg())
                .claim("id", userId)
                .claim("name", user.getName())
                .claim("phone", user.getPhone())
                .setIssuedAt(new Date())
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRE))
                .signWith(SignatureAlgorithm.HS256, SECRET).compact();


        token = TOKEN_PREFIX + token;


        return token;
    }

封装校验token方法

 /**
     * 校验token的方法
     *
     * @param token
     * @return
     */
    public static Claims checkJWT(String token) {


        try {


            final Claims claims = Jwts.parser().setSigningKey(SECRET)
                    .parseClaimsJws(token.replace(TOKEN_PREFIX, "")).getBody();


            return claims;


        } catch (Exception e) {
            return null;
        }


    }

登录整合

                //生成token令牌
                LoginUser userDTO = new LoginUser();
                BeanUtils.copyProperties(userDO, userDTO);
                String token = JWTUtil.geneJsonWebToken(userDTO);
                return JsonData.buildSuccess(token);

第6集请求路径调整+账号微服务注册登录全流程测试

简介：账号微服务之注册登录全流程测试

请求路径调整
注册流程验证
登录流程验证

第7集账号微服务之通用登录拦截器开发和用户信息传递

简介：账号微服务登录拦截器开发和用户信息传递

开发登录拦截器
- 解密JWT
- 传递登录用户信息
  - attribute传递
  - threadLocal传递
SpringBoot拦截器代码开发

@Slf4j
public class LoginInterceptor implements HandlerInterceptor {


    public static ThreadLocal<LoginUser> threadLocal = new ThreadLocal<>();




    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (HttpMethod.OPTIONS.toString().equalsIgnoreCase(request.getMethod())) {
            response.setStatus(HttpStatus.NO_CONTENT.value());
            return true;
        }


        String accessToken = request.getHeader("token");
        if (StringUtils.isBlank(accessToken)) {
            accessToken = request.getParameter("token");
        }




        if (StringUtils.isNotBlank(accessToken)) {
            Claims claims = JWTUtil.checkJWT(accessToken);
            if (claims == null) {
                //未登录
                CommonUtil.sendJsonMessage(response, JsonData.buildResult(BizCodeEnum.ACCOUNT_UNLOGIN));
                return false;
            }


            Long accountNo = Long.parseLong(claims.get("account_no").toString());
            String headImg = (String) claims.get("head_img");
            String username = (String) claims.get("username");
            String mail = (String) claims.get("mail");
            String phone = (String) claims.get("phone");
            String auth = (String) claims.get("auth");


            LoginUser loginUser = LoginUser.builder()
                    .accountNo(accountNo)
                    .auth(auth)
                    .phone(phone)
                    .headImg(headImg)
                    .mail(mail)
                    .username(username)
                    .build();


            //request.setAttribute("loginUser",loginUser);
            //通过threadlocal
            threadLocal.set(loginUser);
            return true;
        }


        return false;
    }


    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {


    }


    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {


        threadLocal.remove();
    }
}

第8集登录拦截器InterceptorConfig拦截和放行路径开发配置

简介：用户微服务登录拦截器路径配置和开发

拦截器配置
- 拦截路径
- 不拦截路径

@Configuration
@Slf4j
public class InterceptorConfig implements WebMvcConfigurer {


    @Override
    public void addInterceptors(InterceptorRegistry registry) {


        registry.addInterceptor(new LoginInterceptor())
                //添加拦截的路径
                .addPathPatterns("/api/account/*/**", "/api/traffic/*/**")


                //排除不拦截
                .excludePathPatterns(
                        "/api/account/*/register","/api/account/*/upload","/api/account/*/login",
                        "/api/notify/v1/captcha","/api/notify/*/send_code");






    }
}

第十章初恋的感觉-海量数据下的分库分表知识阶段一

第1集账号微服务里面的流量包业务模型梳理和需求讲解

简介：账号微服务里面的流量包业务模型梳理和需求讲解

流量包业务模型梳理

在这里插入图片描述

数据量预估（尽量一次性扩容预估好，数据迁移成本大）
- 未来2年，短链平台累计5百万用户
  - 一个用户10条记录/年，总量就是5千万条
  - 单表不超过1千万数据，需要分5张表
  - 进一步延伸，进行水平分表，比如 2张表、4张表、8张表、16张表
- 因为业务逻辑复杂，我们就不分那么多表，分2表操作即可
问题
- 分库分表怎么分？有哪些形式呢? 还会带来哪些问题？
- 比如 2张表、4张表、8张表、16张表这样的思路？
- …更多问题

第2集【面试题】业务增长-数据库性能优化思路讲解

简介：【面试题】业务增长-数据库性能优化思路讲解

面试官：这边有个数据库-单表1千万数据，未来1年还会增长多500万，性能比较慢，说下你的优化思路
思路
- 千万不要一上来就说分库分表，这个是最忌讳的事项
- 一定要根据实际情况分析，两个角度思考
  - 不分库分表
    - 软优化
      - 数据库参数调优
      - 分析慢查询SQL语句，分析执行计划，进行sql改写和程序改写
      - 优化数据库索引结构
      - 优化数据表结构优化
      - 引入NOSQL和程序架构调整
    - 硬优化
      - 提升系统硬件（更快的IO、更多的内存）：带宽、CPU、硬盘
  - 分库分表
    - 根据业务情况而定，选择合适的分库分表策略（没有通用的策略）
      - 外卖、物流、电商领域
    - 先看只分表是否满足业务的需求和未来增长
      - 数据库分表能够解决单表数据量很大的时,数据查询的效率问题，
      - 无法给数据库的并发操作带来效率上的提高，分表的实质还是在一个数据库上进行的操作，受数据库IO性能的限制
    - 如果单分表满足不了需求，再分库分表一起
结论
- 在数据量及访问压力不是特别大的情况，首先考虑缓存、读写分离、索引技术等方案
- 如果数据量极大，且业务持续增长快，再考虑分库分表方案

第3集走进Mysql数据库分库分表后带来的优点和缺点《上》

分库分表解决的现状问题
- 解决数据库本身瓶颈
  - 连接数：连接数过多时，就会出现‘too many connections’的错误，访问量太大或者数据库设置的最大连接数太小的原因
  - Mysql默认的最大连接数为100.可以修改，而mysql服务允许的最大连接数为16384
  - 数据库分表可以解决单表海量数据的查询性能问题
  - 数据库分库可以解决单台数据库的并发访问压力问题

在这里插入图片描述

解决系统本身IO、CPU瓶颈
- 磁盘读写IO瓶颈，热点数据太多，尽管使用了数据库本身缓存，但是依旧有大量IO,导致sql执行速度慢
- 网络IO瓶颈，请求的数据太多，数据传输大，网络带宽不够，链路响应时间变长
- CPU瓶颈，尤其在基础数据量大单机复杂SQL计算，SQL语句执行占用CPU使用率高，也有扫描行数大、锁冲突、锁等待等原因

第4集走进Mysql数据库分库分表后带来的优点和缺点《下》

带来新的问题
- 问题一：跨节点数据库Join关联查询和多维度查询
  - 数据库切分前，多表关联查询，可以通过sql join进行实现
  - 分库分表后，数据可能分布在不同的节点上，sql join带来的问题就比较麻烦

在这里插入图片描述

问题二：分库操作带来的分布式事务问题
- 操作内容同时分布在不同库中，不可避免会带来跨库事务问题，即分布式事务
问题三：执行的SQL排序、翻页、函数计算问题
- 分库后，数据分布再不同的节点上，跨节点多库进行查询时，会出现limit分页、order by排序等问题
- 而且当排序字段非分片字段时，更加复杂了，要在不同的分片节点中将数据进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序（也会带来更多的CPU/IO资源损耗）
问题四：数据库全局主键重复问题
- 常规表的id是使用自增id进行实现，分库分表后，由于表中数据同时存在不同数据库中，如果用自增id，则会出现冲突问题
问题五：容量规划,分库分表后二次扩容问题
- 业务发展快，初次分库分表后，满足不了数据存储，导致需要多次扩容
问题六：分库分表技术选型问题
- 市场分库分表中间件相对较多，框架各有各的优势与短板，应该如何选择
  - 更多问题。。。

第5集海量数据处理之Mysql【垂直分表-垂直分库】讲解

简介：海量数据处理之Mysql数据库垂直分表和分库讲解

需求：商品表字段太多，每个字段访问频次不一样，浪费了IO资源，需要进行优化
垂直分表介绍
- 也就是“大表拆小表”，基于列字段进行的
- 拆分原则一般是表中的字段较多，将不常用的或者数据较大，长度较长的拆分到“扩展表如text类型字段
- 访问频次低、字段大的商品描述信息单独存放在一张表中;
- 访问频次较高的商品基本信息单独放在一张表中
- 垂直拆分原则
  - 把不常用的字段单独放在一张表;
  - 把text，blob等大字段拆分出来放在附表中;
  - 业务经常组合查询的列放在一张表中
- 例子：商品详情一般是拆分主表和附表

//拆分前
CREATE TABLE `product` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(524) DEFAULT NULL COMMENT '视频标题',
  `cover_img` varchar(524) DEFAULT NULL COMMENT '封面图',
  `price` int(11) DEFAULT NULL COMMENT '价格,分',
  `total` int(10) DEFAULT '0' COMMENT '总库存',
  `left_num` int(10) DEFAULT '0' COMMENT '剩余',
  
  `learn_base` text COMMENT '课前须知，学习基础',
  `learn_result` text COMMENT '达到水平',
  `summary` varchar(1026) DEFAULT NULL COMMENT '概述',  
  `detail` text COMMENT '视频商品详情',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;




//拆分后
CREATE TABLE `product` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(524) DEFAULT NULL COMMENT '视频标题',
  `cover_img` varchar(524) DEFAULT NULL COMMENT '封面图',
  `price` int(11) DEFAULT NULL COMMENT '价格,分',
  `total` int(10) DEFAULT '0' COMMENT '总库存',
  `left_num` int(10) DEFAULT '0' COMMENT '剩余',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;


CREATE TABLE `product_detail` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `product_id` int(11) DEFAULT NULL COMMENT '产品主键',
  `learn_base` text COMMENT '课前须知，学习基础',
  `learn_result` text COMMENT '达到水平',
  `summary` varchar(1026) DEFAULT NULL COMMENT '概述',  
  `detail` text COMMENT '视频商品详情',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

需求：C端项目里面，单个数据库的CPU、内存长期处于90%+的利用率，数据库连接经常不够，需要进行优化
垂直分库讲解
- 垂直分库针对的是一个系统中的不同业务进行拆分，数据库的连接资源比较宝贵且单机处理能力也有限
- 没拆分之前全部都是落到单一的库上的，单库处理能力成为瓶颈，还有磁盘空间，内存，tps等限制
- 拆分之后，避免不同库竞争同一个物理机的CPU、内存、网络IO、磁盘，所以在高并发场景下，垂直分库一定程度上能够突破IO、连接数及单机硬件资源的瓶颈
- 垂直分库可以更好解决业务层面的耦合，业务清晰，且方便管理和维护
- 一般从单体项目升级改造为微服务项目，就是垂直分库

在这里插入图片描述

问题：垂直分库分表可以提高并发，但是依然没有解决单表数据量过大的问题

第6集海量数据处理之Mysql【水平分表-水平分库】讲解

简介：海量数据处理之Mysql【水平分表-水平分库】讲解

需求：当一张表的数据达到几千万时，查询一次所花的时间长，需要进行优化，缩短查询时间
都是大表拆小表
- 垂直分表：表结构拆分
- 水平分表：数据拆分
水平分表
- 把一个表的数据分到一个数据库的多张表中，每个表只有这个表的部分数据
- 核心是把一个大表，分割N个小表，每个表的结构是一样的，数据不一样，全部表的数据合起来就是全部数据
- 针对数据量巨大的单张表（比如订单表），按照某种规则（RANGE,HASH取模等），切分到多张表里面去
- 但是这些表还是在同一个库中，所以单数据库操作还是有IO瓶颈，主要是解决单表数据量过大的问题
- 减少锁表时间，没分表前，如果是DDL(create/alter/add等)语句，当需要添加一列的时候mysql会锁表，期间所有的读写操作只能等待

在这里插入图片描述

需求：高并发的项目中，水平分表后依旧在单个库上面，1个数据库资源瓶颈 CPU/内存/带宽等限制导致响应慢，需要进行优化
水平分库
- 把同个表的数据按照一定规则分到不同的数据库中，数据库在不同的服务器上
- 水平分库是把不同表拆到不同数据库中，它是对数据行的拆分，不影响表结构
- 每个库的结构都一样,但每个库的数据都不一样，没有交集，所有库的并集就是全量数据
- 水平分库的粒度，比水平分表更大

在这里插入图片描述

第十一章如漆似胶-海量数据下的分库分表策略讲解

第1集 Mysql数据库水平分库分表常见策略介绍-range

简介： Mysql数据库水平分库分表常见策略介绍-range

水平分库分表，根据什么规则进行？怎么划分？
方案一：自增id，根据ID范围进行分表（左闭右开）
- 规则案例
  - 1~1,000,000 是 table_1
  - 1,000,000 ~2,000,000 是 table_2
  - 2,000,000~3,000,000 是 table_3
  - …更多
- 优点
  - id是自增长，可以无限增长
  - 扩容不用迁移数据，容易理解和维护
- 缺点
  - 大部分读和写都访会问新的数据，有IO瓶颈，整体资源利用率低
  - 数据倾斜严重，热点数据过于集中，部分节点有瓶颈

在这里插入图片描述

第2集 Mysql数据库水平分库分表策略介绍-Range延伸进阶

简介： Mysql数据库水平分库分表常见策略介绍-range延伸

Range范围分库分表，有热点问题，所以这个没用？
- 关于怎么选择分库分表策略问题，如果业务适合就行，没有万能策略！！！！
- 基于方案一：自增id，根据ID范围进行分表延伸解决方案，你能想到多少种
范围角度思考问题 (范围的话更多是水平分表)
- 数字
  - 自增id范围
- 时间
  - 年、月、日范围
  - 比如按照月份生成库或表 pay_log_2022_01、pay_log_2022_02
- 空间
  - 地理位置：省份、区域（华东、华北、华南）
  - 比如按照省份生成库或表

在这里插入图片描述

基于Range范围分库分表业务场景
- 微博发送记录、微信消息记录、日志记录，id增长/时间分区都行
  - 水平分表为主，水平分库则容易造成资源的浪费
- 网站签到等活动流水数据时间分区最好
  - 水平分表为主，水平分库则容易造成资源的浪费
- 大区划分（一二线城市和五六线城市活跃度不一样，如果能避免热点问题，即可选择）
  - saas业务水平分库（华东、华南、华北等）

在这里插入图片描述

第3集 Mysql数据库水平分库分表策略介绍-Hash取模

简介： Mysql数据库水平分库分表常见策略介绍-Hash取模

方案二：hash取模（Hash分库分表是最普遍的方案）
- 为啥不之间取模，如果取模的字段不是整数型要先hash，统一规则就行

在这里插入图片描述

案例规则
- 用户ID是整数型的，要分2库，每个库表数量4表，一共8张表
- 用户ID取模后，值是0到7的要平均分配到每张表
```
库ID = userId % 库数量 2 
表ID = userId / 库数量 2 % 表数量4
```
- 例子
userId id % 2 (库-取余) id /2 % 4 (表)
1 1 0
2 0 1
3 1 1
4 0 2
5 1 2
6 0 3
7 1 3
8 0 0
9 1 0
优点
- 保证数据较均匀的分散落在不同的库、表中，可以有效的避免热点数据集中问题，
缺点
- 扩容不是很方便，需要数据迁移
  表，一共8张表
- 用户ID取模后，值是0到7的要平均分配到每张表
```
库ID = userId % 库数量 2 
表ID = userId / 库数量 2 % 表数量4
```
- 例子
userId id % 2 (库-取余) id /2 % 4 (表)
1 1 0
2 0 1
3 1 1
4 0 2
5 1 2
6 0 3
7 1 3
8 0 0
9 1 0
优点
- 保证数据较均匀的分散落在不同的库、表中，可以有效的避免热点数据集中问题，
缺点
- 扩容不是很方便，需要数据迁移

userId	id % 2 (库-取余)	id /2 % 4 (表)
1	1	0
2	0	1
3	1	1
4	0	2
5	1	2
6	0	3
7	1	3
8	0	0
9	1	0

userId	id % 2 (库-取余)	id /2 % 4 (表)
1	1	0
2	0	1
3	1	1
4	0	2
5	1	2
6	0	3
7	1	3
8	0	0
9	1	0

从零开始学习人工智能

关注

7
点赞
踩
26

收藏

觉得还不错? 一键收藏
打赏
0
评论
海量数据处理商用短链接生成器平台 - 5

简介：账号微服务注册接口介绍和业务代码编写微服务注册接口开发请求实体类编写controllerservice手机验证码验证密码加密（TODO）账号唯一性检查(TODO)插入数据库新注册用户福利发放(TODO)mapper密码存储安全彩虹表暴力破解网站：https://www.cmd5.com/密码存储常用方式双重MD5MD5+加盐双重MD5+加盐简介： Mysql数据库水平分库分表常见策略介绍-range水平分库分表，根据什么规则进行？怎么划分？
复制链接

扫一扫