坪山网站建设服务,短网址生成功能,wordpress 主题 google,广告设计与制作专业就业方向有哪些一#xff0c;什么时聚集索引什么时非聚集索引 聚集索引就是基于主键创建的索引除了主键索引以外的其他索引被称为非聚集索引也叫二级索引由于在innodb引擎里面一张表的数据对应的物理文件本事就是按照B树来组织的一种索引结构而聚集索引就是按照每张表的主键来构建一颗B树然后…一什么时聚集索引什么时非聚集索引 聚集索引就是基于主键创建的索引除了主键索引以外的其他索引被称为非聚集索引也叫二级索引由于在innodb引擎里面一张表的数据对应的物理文件本事就是按照B树来组织的一种索引结构而聚集索引就是按照每张表的主键来构建一颗B树然后叶子结点存储每一张表的每一行数据记录所以基于innodb这样一个特性聚集索引并不仅仅是一种索引类型还代表着一种数据的存储方式同时也意味着每个表里面必须有一个主键如果没有主键innodb会默认选择或者添加一个隐藏列作为主键索引来存储这个表的数据行一般情况下是建议使用自增Id作为主键这样的话id本身具有连续性使得对应的数据也会按照顺序存储在磁盘上写入性能和搜索性能都很高否则如果我们使用uuid这种随机id那么在频繁插入数据的时候就会导致随机磁盘IO从而导致性能比较低。需要注意的是innodb只能存在一个聚集索引原因很简单如果存在多个聚集索引那么意味着这个表里面的数据会存在多个副本造成磁盘空间浪费以及数据维护困难的问题由于在innodb里面主键索引表示的是一种数据存储结构所以如果是基于非聚集索引来查询一条完整记录最终还是需要访问主键索引来检索。 二什么是双亲委派 首先简单说一下类的加载机制就是我们自己写的java源文件到最终的运行必须要经过编译和类加载两个阶段编译的过程就是把Java编译成.class文件。类加载的过程呢就是把.class文件装载到jvm内存里面装载完成以后就会得到一个class对象我们就可以使用new关键字来实例化这个对象而类加载的过程需要涉及到类加载器 jvm在运行中会产生三个类加载器这三个类加载器组成了一个层级关系每个类加载器分别去加载不同作用范围的jar包比如 1Bootstrap ClassLoader启动类加载器 主要负责加载Java核心类库%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。 2Extention ClassLoader扩展类加载器主要负责加载目录%JRE_HOME%\lib\ext目录下的jar包和class文件。 3Application ClassLoader应用程序类加载器 主要负责加载当前应用的classpath下的所有类 除了系统提供的类加载器以外还可以通过ClassLoader这个类来实现自定义类加载器去满足一些特殊场景的需求 而父委派模型就是按照类加载器的层级关系逐层进行委派比如需要加载一个class文件的时候首先会把这个class的查询和加载委派给父加载器去执行如果父加载器都无法加载在尝试自己去加载这个class。 这样设计的好处呢我认为的好处呢有几个 1安全性 因为这种层级关系实际上代表的是一种优先级也就i是所有的类加载优先给BootstrapClassLoader 那么对于核心类库中的类就没办法被破坏比如自己去写一个java.lang.String最终还是会交给启动类加载器来加载在加上每个类加载器的作用范围那么自己写的java.lang.String就没有办法去覆盖类库中的类。 2这种层级关系的设计可以避免重复加载导致程序混乱的问题因为如果父类加载器已经加载过了那么子类就没有必要去加载了这就是整个类加载器的工作原理 三.Redis 和 Mysql 如何保证数据一致性 一般情况下Redis 用来实现应用和数据库之间读操作的缓存层主要目的是减少数据库 IO还可以提升数据的 IO 性能。这是它的整体架构。 当应用程序需要去读取某个数据的时候首先会先尝试去 Redis 里面加载如果命中就直接返回。如果没有命中就从数据库查询查询到数据后再把这个数据缓存到 Redis 里面。 在这样一个架构中会出现一个问题就是一份数据同时保存在数据库和 Redis里面当数据发生变化的时候需要同时更新 Redis 和 Mysql由于更新是有先后顺序的并且它不像 Mysql 中的多表事务操作可以满足ACID 特性。所以就会出现数据一致性问题。 在这种情况下能够选择的方法只有几种。 先更新数据库再更新缓存先删除缓存再更新数据库如果先更新数据库再更新缓存如果缓存更新失败就会导致数据库和 Redis中的数据不一致。 如果是先删除缓存再更新数据库理想情况是应用下次访问 Redis 的时候发 现 Redis 里面的数据是空的就从数据库加载保存到 Redis 里面那么数据是 一致的。但是在极端情况下由于删除 Redis 和更新数据库这两个操作并不是原 子的所以这个过程如果有其他线程来访问还是会存在数据不一致问题。 所以如果需要在极端情况下仍然保证 Redis 和 Mysql 的数据一致性就只能 采用最终一致性方案。 比如基于 RocketMQ 的可靠性消息通信来实现最终一致性。 四。死锁的发生原因和怎么避免 死锁简单来说就是两个或者两个以上的线程在执行的过程中争夺同一个共享 资源造成的相互等待的现象。 如果没有外部干预线程会一直阻塞无法往下执行这些一直处于相互等待资源 的线程就称为死锁线程。 导致死锁的条件有四个也就是这四个条件同时满足就会产生死锁。 互斥条件共享资源 X 和 Y 只能被一个线程占用请求和保持条件线程 T1 已经取得共享资源 X在等待共享资源 Y 的时候不释放共享资源 X不可抢占条件其他线程不能强行抢占线程 T1 占有的资源 循环等待条件线程 T1 等待线程 T2 占有的资源线程 T2 等待线程 T1 占有的资源就是循环等待。导致死锁之后只能通过人工干预来解决比如重启服务或者杀掉某个线程。所以只能在写代码的时候去规避可能出现的死锁问题。按照死锁发生的四个条件只需要破坏其中的任何一个就可以解决但是互斥条件是没办法破坏的因为这是互斥锁的基本约束其他三方条件都有办法来破坏对于“请求和保持”这个条件我们可以一次性申请所有的资源这样就不存在等待了。对于“不可抢占”这个条件占用部分资源的线程进一步申请其他资源时如果申请不到可以主动释放它占有的资源这样不可抢占这个条件就破坏掉了。对于“循环等待”这个条件可以靠按序申请资源来预防。所谓按序申请是指资源是有线性顺序的申请的时候可以先申请资源序号小的再申请资源序号大的这样线性化后自然就不存在循环了。
