Redis

写在前面 又到了收割Offer的季节，你准备好了吗？曾经的我，横扫各个大厂的Offer。还是那句话：进大厂临时抱佛脚是肯定不行的，一 定要注重平时的总结和积累，多思考，多积累，多总结，多复盘，将工作经历真正转化为自己的工作经验。 面经分享 今天给大家分享一个面试大厂的完整面经，小伙伴们可以对照下，这些面试题自己是否都会了呢？ 同时后面还整理了这些问题的一套面试解析文档及架构学习笔记资料，有需要的小伙伴 一轮技术面（90分钟） hashmap和hashtable区别 为什么会产生死锁 jvm类加载 java反射获取私有属性，改变值 反射用途 所用数据库 项目难点，问题 如何解决项目中遇到的问题 项目中遇到的最难解决的地方 二轮技术面（120分钟） 讲项目 数据库乐观锁使用 如何分库分表 MySQL极限 HashMap源码 设计一个线程安全的HashMap 快排的实现，时间复杂度和空间复杂度 会什么算法 如何把项目变成SOA架构 Spring源码，最深刻的模块，aop用途 JVM内存模型 垃圾回收机制 项目中查看垃圾回收 三轮技术面（150分钟） ConcurrentHashMap底层原理？ 手写一个LRU（用LinkedHashMap） HashMap底层数据结构？ JDK1.8中的HashMap为什么用红黑树不用普通的AVL树？ 为什么在8的时候链表变成树？

本期是读者投稿，他跟他聊的时候发现这个小伙子挺有意思的，是个校招生，全靠白嫖B站和我们一群号主的面试题复习，拿了挺多offer的，大家看看他的准备过程，校招的朋友可以看看他的学习路线。 读者介绍 目前他是电子科技大学的一名大三学生，在大一大二两年，主要的精力都用来准备校内课程学习。 在今年的十月份开始准备 Java 实习面试，目前陆续拿到了滴滴、华为、字节跳动的实习offer（最后跟我讨论一番大概率去字节的基础架构研发实习） 复习过程 10月第一周：看完 JavaGuide的面试突击版中的 Java 基础部分 10月第二周：开始看 B 站上看狂神说视频，学习 Spring 和 SpringBoot 开发，完成项目的初步搭建，看 Shiro 的权限管理和 JWT，为项目加入 Mysql、 Redis(之前有项目开发基础) 10月第三周：看 B站上 马士兵的 2020年9月 JAVA 面试必问的102个知识点（全部弄懂记住），配合 JavaGuide 的面试突击版一起看 10月第四 - 五周：发现了 敖丙的北大面试视频（每看到一个不会的知识点就暂停，去公众号找对应的文章去看，直到看懂整个视频），基本把公众号里的50%的内容都看懂，能够自己复述一遍，后面去敖丙github把面经和文章撸一遍基本上面试点都刷完了 11月第一 - 二周：开始投了第一家面试公司（跟谁学）

1. 参考资料 https://docs.spring.io/spring-session/docs/current/reference/html5/guides/boot-redis.html https://docs.spring.io/spring-boot/docs/2.0.2.RELEASE/reference/htmlsingle/#boot-features-session 2. 环境 Java: jdk1.8.0_144 Spring Boot: 2.0.1.RELEASE 3. 配置 本文前提是已使用Spring Boot搭建了一个Web应用，在此基础上集成Spring Session以使用Redis管理该应用的session 引入依赖包 <dependency> <groupId>org.springframework.session</groupId> <artifactId>spring-session-data-redis</artifactId> </dependency> <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> </dependency> Spring Session配置 spring.session.store-type=redis

华为云学院带你 7天入门Redis（4） Redis实例配置参数 1、操作场景和限制介绍 什么是数据结构？ 1.基于内存的key-value数据库 2.基于c语言编写的，可以支持多种语言的api //set每秒11万次，取get 81000次 3.支持数据持久化 4.value可以是string，hash， list， set, sorted set 使用场景 1. 取最新n个数据的操作 2. 排行榜，取top n个数据 //最佳人气前10条 3. 精确的设置过期时间 4. 计数器 5. 实时系统， 反垃圾系统 6. pub， sub发布订阅构建实时消息系统 7. 构建消息队列 8. 缓存 keys键操作 Redis是一种高级的key-value的存储系统，其中的key是字符串类型，尽可能满足如下几点：  key不要太长，最好不要超过1024个字节，这不仅会消耗内存还会降低查找效率  key不要太短，如果太短会降低key的可读性  在项目中，key最好有一个统一的命名规范（根据企业的需求） 常用的Keys键操作命令有：  exists-----测试key是否存在  del-----删除key  type-----返回key的类型  keys-----匹配满足的key  rename------改key名  dbsize-----当前数据库key的数量 

想写这个是源于微信群里面的一个讨论。在讨论分布式系统的时候，有群友明确地如下说： CAP是可以兼顾的啊！ 这把我惊起了一身冷汗，赶紧去查了一下是不是分布式系统理论界又有新的论文来推翻了之前的CAP定理了。后来深入讨论以后，才发现是他对CAP的理解有误。 CAP理论是分布式领域的基础，所以大家的讨论和研究很多。学界和工业界也想出来好多办法来折中处理不可兼得时候的情形，例如著名的“BASE"。但是诸如上面的“CAP可以兼顾”的话是绝对不应该出现的。如果能证明这点并且能写出学术文章的话，那是肯定能发 PODC 并且成为学术大牛的。而现阶段的研究没有一个往着打破CAP定理的方向走，这说明CAP定理挺牢固的，只是因为“BASE”的存在而产生好像兼顾了的误解。那么，为了帮助大家更好的理解CAP及其应用呢，借此机会，我来试着写篇文章讨论一下这方面的内容，并且争取能通过实践将其表达的更加清楚。 CAP定理到底是什么 以下定义摘自维基百科： 在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点： 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本） 可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据） 分区容错性