问题一:数据库中两张表join连接查询的时候,索引是怎么走的呢?这个连接查询的底层过程是怎么进行的呢?一般说是两表连接时连接的字段要加上索引,效率会高,请问这是基于什么原理呢?关联查询时,“小表驱动大表”怎么理解?

首先连接查询会有一个表作为驱动表,一个表是被驱动表。

驱动表可以理解为正常的单表查询,所以效率主要就是看,怎么根据驱动表的查询数据,去查被驱动表的数据。如果说关联字段没有索引,那查被驱动表的时候,就相当于全表扫描了,效率肯定低。

为什么是“小表驱动大表”?

有两个变量会影响查询效率,一是“单次查询被驱动表的效率”,而是“查询被驱动表的次数”。

这里分两种情况,第一种是"关联字段有索引",第二种是“关联字段没有索引”

关联字段有索引

这种情况,通过索引查询被驱动表时大表和小表,对于单词查询被驱动表的效率不会相差很多。 所以就看被驱动表的查询次数了。查询次数其实就是取决于驱动表的查询结果,驱动表的结果,是被驱动表的查询条件,所以驱动表查询结果越小,查询次数就越少了。所以小表驱动大表效率会更高。

注意:小表指的是驱动表查询结果少。而不是说驱动表的表容量小。注意下这里的误区。

join查询的是一张表一张表的按顺序来查询的。

关联字段没有索引

mysql为了避免多次全表扫描被驱动表,会把驱动表查询结果的相关数据缓存起来,然后通过这个缓存去全表扫描被驱动表。但是这个缓存大小是有限的,如果驱动表查询结果相关数据大于这个阈值,那么就要分成多次去全表扫描被驱动表。次数决定了效率。

举例:比如驱动表查询的结果是(1、2、3、4、5、6),现在要拿着这个结果去被驱动表查询。有两种做法,一种是从(1、2、3、4、5、6)一个个取出数据去被驱动表查询,这种做法就是被驱动表要6次全表扫描。还有一种做法是,我拿着(1、2、3、4、5、6)作为一个集合,去被驱动表查询,这样只需要一次全表扫描。假设缓存大小是3,而驱动表查询结果是6,那只能分两次(1、2、3)(4、5、6)去扫描被驱动表了。

问题二:请求响应断连如何解决?比如说请求下单之后,网络断开了,我们这边请求没接收到下单的结果怎么办?

这种情况状态属于未知,一般是拿着订单号再去服务端查询结果。

问题三:和第三方系统对接(比如使用http接口调用)时,常见的保证安全性的方案有哪些呢?

安全保障一般包括这几个方面 1、数据来源可靠

数据来源可靠,可以通过证书解决。。收到请求时,去验证证书是不是合法的。

2、数据防止被泄露

数据防止被泄露,一般就是加密了。

3、数据防止被串改。

防串改,可以把请求的参数按照某个规则组合起来,然后生成一个一串指纹串一并传到服务端。。服务端收到数据后按照同样的规则生成指纹串,和客户端传过来的指纹串进行比较

问题四:为什么Redis要用跳表来实现有序集合,而不是红黑树、B+树?

大概有以下几点:

1.跳表的实现比较简单

2.redis需要范围查询,跳表的范围查询更加容易

首先每个数据结构都有一些自己适用的场景,没有绝对好与坏,只有适用与不适用。

回答这个题目,我觉得应该包括两个方面 1)redis 的适用场景,也就是说sorted set这个类型,它提供什么样的能力。

2)各个数据结构的特点是怎样子的,满足sorted set对外能力是否合适

从功能方面来说,范围查询、查排名、查分数这些功能是redis需要满足的。

范围查询的话,范围查询的话,红黑树的效率会低一些,红黑树的范围查找:找到指定范围的最小值之后,还需要以中序遍历的顺序继续寻找其它不超过最大值的节点。效率不如链表高。

查排名 本质上是定位元素,如果单纯比较性能,跳跃表和红黑树、B+树可以说相差不大 如果要更新数据,跳跃表需要更新的部分就比较少,锁的东西也就比较少,所以不同线程争锁的代价就相对少了,而红黑树和B+树有个平衡的过程,牵涉到大量的节点,争锁的代价也就相对较高了。性能也就不如前者了。

b+树最主要的特点是磁盘友好一些,为了减少磁盘寻址的次数,一个节点会存在多个元素。

所以并不像红黑树或者跳表,能立即定位到元素。

跳表的相对其他数据结构是比较占空间的,在redis的实现中,抛开层数不说,跳表至少是一个双向链表。

b+的叶子节点也组成了双向链表,b+树的查找效率,理论上是对低一些的。b+树最主要的特点是磁盘友好一些,为了减少磁盘寻址的次数,一个节点会存在多个元素。所以并不像红黑树或者跳表,能立即定位到元素。

问题五:某个图片共享社区,通过redis保存图片数据库ID与对象存储文件ID,图片ID和文件ID都是10位数(如:1631267833)该映射关系,如何存储?

这道题最简单的方式就是直接用string,key是图片id,value是文件id。

但是空间占用会比较大。

所以一种常见的方法是使用hash,把图片id,拆分成两部分,前7位是key,后3位是field,同时配合把使用压缩列表hash集合最大个数调整位1000.。 由于fieldId是3位数不超过1000,可以确保每个hash结构都是使用压缩列表。可以降低空间。

问题六:Redis的rehash过程?

因为redis的命令是单线程的,如果一个命令触发了rehash,那可能是非常耗时的,所以redis的rehash是渐进式的。所谓的渐进式,就是不立马扩容。反应到数据实现上就是用两个hashtable,比如扩容的时候,一个是旧的(扩容前),一个是新的(扩容后的)。rehash的过程应该说不是一次性完成,分多次完成。

问题七:多个客户端去请求多个服务器中的共享资源,除了用分布式锁还用什么方案解决?

对共享资源的操作,如果不是原子的,肯定会涉及到锁的问题的。

问题八:“java中synchronized底层有三种锁的实现,包括偏向锁、轻量级锁、重量级锁,还提供了自动的升级和降级机制”,这里怎么理解锁的升级降级?

简单来说: 偏向锁:只有一个线程请求锁资源时,采用偏向锁 轻量级锁:多个线程请求锁资源时,未抢到锁的线程不阻塞,而是自旋等待 重量级锁:多个线程请求资源时,未抢到锁的线程阻塞,等待唤醒。 三个锁成本依次递增。重量级锁和轻量级锁的区别是,抢不到锁会阻塞,但轻量级锁不阻塞,而是继续尝试获取锁(自旋)。

问题九:文件的上传下载时,怎么实现的断点续传功能?

就是要记录当前的上传或者下载的位置,然后使用这个位置去读取文件。。就能实现断点续传了。 RandomAccessFile 可以指定从某个位置开始读取文件,所以只要记录当前已经读取到哪个位置了,再结合RandomAccessFile就能实现断点下载了。注意这里是在客户端进行记录就可以。 如果服务端如果挂掉了,那就是另外一回事, 要考虑如何做高可用。

问题十:Redis中有RDB和AOF两种持久化模式,这两种持久化方式如何选择?

Redis是内存数据库,宕机后数据会消失。 Redis重启后快速恢复数据,要提供持久化机制 Redis持久化是为了快速的恢复数据而不是为了存储数据。

Redis有两种持久化模式:RDB和AOF。

RDB:RDB方式是通过快照(snapshotting)完成的。这一刻的数据,不关注过程。

AOF:AOF(append only file)是Redis的另一种持久化方式。 Redis 将所有对数据库进行过写入的命令(及其参数)(RESP)记录到 AOF 文件, 以此达到记录数据库状态的目的,这样当Redis重启后只要按顺序回放这些命令就会恢复到原始状态了。

区别:

  1. AOF会记录过程,RDB只管结果。
  2. RDB存某个时刻的数据快照,采用二进制压缩存储,AOF存操作命令,采用文本存储(混合);
  3. RDB性能高、AOF性能较低;
  4. RDB在配置触发状态会丢失最后一次快照以后更改的所有数据,AOF设置为每秒保存一次,则最多 丢2秒的数据;