大数据高薪课程

时间:2021-11-17 来源:未知网络 作者:996建站网

本文来自一位外包公司3年数仓工作经验,一直在自学突破瓶颈的路上苦苦挣扎,直到遇见拉勾….

一、初识拉勾教育

最开始并不知道拉勾有教育模块的业务,一直都以为只有招聘。直到今年7月份的时候拉勾的小姐姐打电话给我说他们有一个训练营问我是否有兴趣,那个时候刚好处于技术的瓶颈期,对于技术感觉怎么都上不去。于是就听了拉勾小姐姐的介绍(拉勾教育大数据高薪训练营课程),主要介绍从以下几个方面讲解:

1、大数据高薪训练营课程大纲介绍

大数据高薪训练营是拉勾教育历经十二个月时间精心打磨才确定推出的课程。课程知识体系覆盖全面,详细规划层层递进提升技术能力,涵盖了99%的企业对技术的要求。课程内容分两个阶段,预科阶段和正式阶段,内容涵盖JavaSE 和 Java Web数据可视化,Hadoop核心及生态圈技术栈,分布式缓存Redis及Kafka消息中间件,内存级快速计算引擎Spark,新一代计算利器Flink,大数据新技术实践(最近比较火热的,强悍的俄罗斯人研究的ClickHouse等),大数据处理算法及案例,机器学习及五个实战项目等。其中还有拉勾自己的项目实战。讲师团队都是由一线多年经验的资深技术专家讲解,更加贴近实际开发应用。

2、课程学习模式介绍

线上学习直播+录播,课程阶段学习闯关式。只有前面的阶段学完提交作业老师批改及格才解锁下一个模块。

3、导师在线实时解答疑惑,进行作业思路指导与批改。

4、班主任在线监督学习情况。

二、选择拉勾原因

​ 听完了训练营的课程介绍后,还是比较激动因为课程内容很符合自己目前的情况,但是依然很淡定,因为我要反复对比课程内容选择最好的。对比了其他平台课程发现内容都没有拉勾教育的系统和全面,最终在7.23那天缴费参与了课程。做出这个决定比较难,因为学费不便宜(大家一定这样觉得)。但是这个费用和以后的职业提升发展做对比,我还是觉得可以承受的。毕竟未来还很长,而且学习一周不满意可以全额退款。如果觉得学的不够好还可以免费读一次,那么就可以学习一年。

拉勾训练营能够做到:

1.想要有一个完整的大数据知识架构

2.体验实实在在公司级别的项目流程

3.进大厂的机会

三、学习过程亲身感受

​ 以前都是自己学习,整体学下来回感觉到很痛苦。毕竟技术的道路不太好走,没有人带领也不知道应该如何做,整体的知识体系会比较乱、还会松懈。在加入了拉勾的训练营后,每天都要学习2-3个小时,跟着老师的脚步慢慢学。松懈的时候看到与别人的进度有差距,这个时候不服输的心理就诞生了,促使这我继续坚持学习下去。

​ 在课程上,我总是从网上找过的课相比,最大的感受就是拉勾强调基础打稳、把知识点联动学习和从真正公司和项目的角度去分析这个知识点以后在工作中会发挥的作用。这是目前我在别的视频中找不到的点。

另外就是用一个大数据领域常听到的词来评价拉勾训练营的教学体系就是耦合度不高,负责不同领域讲课的老师、负责批改作业和答疑解惑的导师、负责协调进度解决非技术性问题的班班。所以能做到每个部分都不会出现忙不过来让学生等太久的问题。

虽然都说不管什么样的学习方式、什么样的学习机构都是看个人的努力,这句话是没错的,但是一个科学化的训练营是可以做到能让人在最短时间内学到既多又精确面向工作的认识的,至少现在的学习阶段拉勾让我感受到了这一点。

班主任和导师很热情认真负责,信息回复很及时。班主任和导师分别负责服务类和技术类的问题。在班群中班主任会不时的给大家打气,在学习中缓解了我们的紧张气氛,还营造了很好的学习氛围。如果对于课程有什么不理解的咨询班主任也会第一时间的到答复。说到最主要的技术问题,班群的讨论氛围也是热烈的。如果有问题可以在班群提出,那么有空的同学会给予答复,当然大家都解决不了的时候导师会给你解答。很多同学都是晚上提交作业,导师也会第一时间批改给你开下一个模块让你可以学习,不耽误你的学习时间。

结合我之前自学的知识点整理的学习笔记

redis笔记:

1.RDB和AOF持久化

  • RDB持久化以指定的时间间隔内的Key的变化量,对内存中的数据进行全量持久化一次。
  • AOF持久化记录Redis接收的每一个写操作,记录到aof文件中,对key过期的,会写入一条del命令,当执行AOF重写时,会忽略过期的key和del命令。

RDB

RDB的配置,在redis.conf中配置 save “” #不使用RDB存储 不能主从 save 900 1 #表示15分钟(900秒钟)内至少1个键被更改则进行快照。 save 300 10 #表示5分钟(300秒)内至少10个键被更改则进行快照。 save 60 10000 #表示1分钟内至少10000个键被更改则进行快照 RDB原理

大数据高薪课程插图

  • RDB是二进制压缩文件,占用空间小,便于传输
  • RDB主进程Fork子进程,可以最大优化Redis性能。Redis中数据量不能太大,复制过程中主进程会阻塞
  • RDB不保证数据完整性,会丢失最后一次快照以后更改的所有数据

AOF

AOF配置,在redis.conf中配置 是否开启aof appendonly yes #⽂文件名称 appendfilename “appendonly.aof” #同步⽅方式 appendfsync everysec #aof重写期间是否同步 no-appendfsync-on-rewrite no #重写触发配置 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb #加载aof时如果有错如何处理理 #yes表示如果aof尾部⽂文件出问题,写log记录并继续执⾏行行。no表示提示写⼊入等待修复后写⼊入 aof-load-truncated yes #⽂文件重写策略略 aof-rewrite-incremental-fsync yes appendfsync同步模式 always:把每个写命令都⽴立即同步到aof,很慢,但是很安全 everysec:每秒同步一次,是折中⽅方案,可能会丢失1秒数据 no:redis不不处理理交给OS来处理理,⾮非常快,但是也最不安全

2.缓存问题

2.1缓存的读写模式

最经典的缓存加数据库读写模式 读取数据模式:读的时候,先写缓存,缓存没有的话,就读取数据库,然后取出数据后放入缓存,同时返回响应 更新数据模式:更新的时候,先更新数据库,然后再删除缓存 此种模式下面高并发脏读三种情况

  • 1、先更新数据库在更新缓存:update与commit之间,更新缓存缓存,commit失败则DB与缓存数据不一致
  • 2、先删除缓存在更新数据库:update与commit之间,有新的读,缓存空,读DB数据到缓存数据是旧数据,commit后DB为新数据,而DB与缓存数据不一致
  • 3、先更新数据库在删除缓存(推荐):update与commit之间,有新的读,缓存空,读DB数据到缓存 数据是旧的数据,commit后DB为新数据,则DB与缓存数据不一致。可以采用延时双删策略

2.2缓存过期和淘汰策略

  • 通过在redis.conf中 设置 maxmemory 如 maxmemory 1024mb 进行设置Redis最大内存限制
  • 通过expire命令的设置key的生存时间: expire key ttl(单位秒)
  • 通过在redis.conf文件中可以配置key主动删除策略,默认是no-enviction(不删除):maxmemory-policy allkeys-lru
  • volatile为前缀的策略都是从已经过期的数据集中进行淘汰。
  • allkeys为前缀的策略都是面向所有key进行淘汰
  • lru最近最少用到的
  • lfu最不常用
  • 触发条件都是Redis使用内存达到设置阈值时

2.3缓存穿透

缓存穿透是指在高并发下查询Key不存在的数据,会穿透查询数据。导致数据压力过大而宕机。 解决方案:

  • 1、对查询结果为空的情况也进行缓存。缓存时间(ttl)设置短一些,或者该key对应的数据insert了之后清理缓存。但是会带来一定的问题,缓存太多空值占用了更多的空间。
  • 2、使用布隆过滤器BloomFilter。在缓存之前加一层布隆过滤器,在查询的时候先去布隆过滤器查询key 是否存在,如果不存在就直接返回,存在在查询缓存和DB.

3.Redis的BloomFilter 原理

  • 是由一个很长的二进制数组,初始数组每个值为0。
  • 新增,通过hash算法,计算这个key对应的下标值设置为1。
  • 查询时,通过hash算法,计算这个key对应数组下标的值,如果对应下标值为0,则这个key一定不存在,如果下标值为1则可能存在。
  • 由于hash碰撞,有一定的误判率,一般通过计算多个函数值减少误判率。它的优点是空间效率和查询时间都远远超过一般的算法。

大数据高薪课程插图

4.缓存雪崩

  • 缓存雪崩:Redis服务器重启或者大量缓存集中在某一个时间段失效,会给DB造成很大压力。也就是说,突然间大量的key失效或者redis重启(redis重启加载持久化的数据也需要一定时间),这个时间大量请求访问,会造成DB瞬间的巨大的压力,数据库崩溃。
  • 解决方案:1、key的失效期分散开 不同的key设置不同的有效期;2、设置二级缓存(数据不一定一致);3、高可用(脏读)

5.缓存击穿

  • 缓存击穿是针对少量key,缓存雪崩是针对大量key。缓存击穿:对一些设置了过期时间的key,在某一段时间点被大量访问,恰好在这个时间点过期了,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。 解决方案:
  • 1、用分布式锁控制访问的线程。使用redis的setnx互斥锁先进行判断,这样其他线程就处于等待状态,保证不会有大并发操作去数据库。
  • 2、不设置超时时间,单会造成写一致问题。当数据库发生更新时,缓存中的数据不会及时更新,这样会造成数据库中的数据与缓存中的数据的不一致,樱花会从缓存中读取到脏数据。可以采用双删策略处理。

数据不一致问题

缓存和DB的数据不一致的根源:数据源不一样。 先更新数据库再更新缓存或者先更新缓存再更新数据库,本质上不是一个原子操作,高并发情况下会产生不一致 保证数据的最终一致性(延时双删)

  • 1、先更新数据库同时删除缓存项(key),等读的时候在填充缓存
  • 2、几秒后在删除一次缓存项(key)
  • 3、设置缓存过期时间Expired Time比如10秒或者1分钟等
  • 4、将缓存删除失败记录到日志中,利用脚本提取失败记录再次删除
  • 5、通过数据库的binlog来异步淘汰key,利用工具(canal)将binlog日志采集发送到MQ中,然后通过ACK机制确认处理删除缓存。

6.数据并发竞争

Redis的多个client同时set 同一个key引起的并发问题。

  • 同时并发写一个key,一个key的值是1,本来按顺序修改为2,3,4,最后是4,但是顺序变成了4,3,2,最后变成了2。

第一种方案:分布式锁+时间戳

  • 分布式锁可以用setnx进行实现,加锁把并行读写改成串行读写的方式,从而来避免资源竞争。如系统AB需要进行set值
  • 系统A key 1 {ValueA 8:00} 系统B key 1 { ValueB 8:05},假设系统B先抢到锁,将key1设置为{ValueB 8:05}。接下来系统A抢到锁,发现自己的key1的时间戳早 于缓存中的时间戳(8:00<8:05),那就不做set操作了.

第二种方案:利用消息队列

  • 在并发量过大的情况下,可以通过MQ进行处理,把并行读写进行串行化,把Redis的set操作放在队列中使其串行化,必须的一个一个执行。

7.Hot Key

当有大量的请求(几十万)访问某个Redis某个key时,由于流量集中达到网络上限,从而导致这个redis的服务宕机。造成缓存击穿,接下来对这个key的访问会造成数据库崩溃,或者访问数据库回填Redis再访问Redis,继续崩溃。 如何发现热Key

  • 1、预估热key,如秒杀商品等;
  • 2、在客户端进行统计;
  • 3、如果是代理,可以在代理端统计;
  • 4、基于实时计算进行发现

如何处理热key

  • 1、变分布式缓存为本地缓存,如Ehcache、Guava Cache;
  • 2、在每个Redis主节点上备份热key数据,读取时采用随机读取,将访问压力分发到各个节点;
  • 3、利用对热点数据访问进行限流熔断保护措施,限制每秒限制最多限制读多杀次[如4W次],一次超过就可以熔断,不让请求缓存集群,直接返回静态信息,用户稍后重试,进行保护缓存系统。

8.Big Key

大Key指的是存储的值(Value)非常大、常见场景:热门话题的讨论、大V的粉丝列表、序列化后的图片等 大key的影响

  • 1、大key会大量占用内存,在集群中无法均衡;
  • 2、Redis的性能下降,主从复制异常;
  • 3、在主动删除或过期删除时会操作时间过长而引起服务阻塞

如何发现大key:

  • 1、使用Redis自带命令:redis-cli –bigkeys命令,当redis中key比较多时,执行慢。以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key;
  • 2、获取生产Redis的rdb文件,通过rdbtools分析rdb生成csv文件,再导入MySQL或其他数据库中进行分析统计,根据size_in_bytes统计bigkey

大key的处理:

  • 1、减少String的字符串长度,list、hash、set、zset等的成员。string 类型的大key可以存放在其他的服务上如CDN。或者把大key存在在单独的Redis节点进行存储,和其他的key进行分开。
  • 2、删除大key时不要使用del命令,del是阻塞命令、删除时会影响性能。使用lazy delete(unlink命令)

9.分布式锁特性

互斥性:任意时刻,只能有一个客户端获取锁,不能同时有两个客户端获取到锁。redis:setnx 如果如果不存在就不设置 同一性:锁只能被持有改锁的客户端删除,不能由其它客户端进行删除。redis:lua实现原子性 可重入性:持有某个锁的客户端可继续对该锁加锁,实现锁的续租 容错性:锁失效后(超过生命周期)自动释放锁(key失效),其他客户端可以继续获得该锁,防止死锁。redis:set key value NX PX

watch

利用Watch实现Redis乐观锁。乐观锁(CAS):比较并替换,是不具有互斥性,不会产生锁等待而消耗资源,但是需要反复的重试,但也是因为重试的机制,能比较快的响应。

// 模拟秒杀场景
public class TestWatch {
	private static String rediskey = "lock_mx";
	public static void main(String[] args) {
		LinkedBlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>(1100);
		ThreadPoolExecutor executor = new ThreadPoolExecutor(20, 40, 10, TimeUnit.SECONDS, queue);
		Jedis jedis = new Jedis("127.0.0.1", 6379);
		// 初始化
		jedis.set(rediskey, "0");
		jedis.close();
		
		for (int i = 0; i < 1000; i++) {
			executor.execute(()->{
				myWatch();
			});
		}
	}
	
	public static void myWatch() {
		Jedis jedis = new Jedis("127.0.0.1", 6379);
		try {
			jedis.watch(rediskey);
			String val = jedis.get(rediskey);
			int num = Integer.parseInt(val);
			
			String userInfo = UUID.randomUUID().toString();
			if(num < 20) {
				Transaction tr = jedis.multi();
				tr.incr(rediskey);
				List<Object> list = tr.exec();
				if(list != null && list.size() > 0) {
					// 秒成功  失败返回空list而不是空
					System.out.println("用户:" + userInfo + ",秒杀成功!当前成功人数:" + (num + 1));
				} else {
					// 版本变化,被别人抢了
					System.out.println("用户:" + userInfo + ",秒杀失败");
				}
			} else {
				System.out.println("已经有20人秒杀成功,秒杀结束");
			}
		} catch (NumberFormatException e) {
			e.printStackTrace();
		}finally {
			jedis.close();
		}
	}
}

大数据高薪课程插图1

微信扫一扫 关注公众号

微信扫一扫 使用小程序

百度扫一扫 使用小程序