笔记

最新推荐文章于 2024-08-23 21:32:35 发布

silence2018

最新推荐文章于 2024-08-23 21:32:35 发布

阅读量143

点赞数

为什么要进行分表分库，分表分库的优缺点

因为数据库或者数据表里的数据会越来越多，查询速度就会越来越慢，分库分表可以解决这个问题，每个表里只存限制条数的数据，超出了就创建新表。但其实只要数据库结构合理，加上适当优化，上亿的数据记录都没问题的。所以不一定非得分库分表，要是结构优化得不好，分库分表反而会造成更多的问题。

1 基本思想之什么是分库分表？
从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。
2 基本思想之为什么要分库分表？
数
据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增
删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、
数据处理能力都将遭遇瓶颈。
3 分库分表的实施策略。
分库分表有垂直切分和水平切分两种。
3.1
何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据
库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。
3.2
何谓水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库
上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、
part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，
然后将这些表按照一定的规则存储到多个userDB上。
3.3 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。
而
如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体
的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。
4 分库分表存在的问题。
4.1 事务问题。
在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
4.2 跨库跨表的join问题。
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
4.3 额外的数据管理负担和数据运算压力。
额
外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于
一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order
by语句就可以搞定，但是在进行分表之后，将需要n个order
by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。

zookeeper在分布式服务中起什么作用

Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理、Leader 选举、队列管理等。

Zookeeper是什么

是一个为用户的分布式应用程序提供协调的服务
也是为别的分布式程序服务的
本身也是一个分布式程序(只要半数以上节点存储，就能正常提供服务)
集群里解决的问题：

Zookeeper上面刚提到，它是为别的分布式程序服务的。所以在高可用的也是用来服务，当然还有别的作用。Zookeeper是普通集群转变为高可用的重要手段，解决了单点故障的问题。ZooKeeper Server是奇数个的，是因为zookeeper中的选举机制，必须选举出超过一半以上的结果，来决定谁是Mster,用来防止脑裂

如果一个发布的服务死了，地址调用中心怎么知道

https://blog.csdn.net/erica_1230/article/details/50636821

java怎么新建一个线程，有哪几种方式

https://blog.csdn.net/longshengguoji/article/details/41126119

怎么启动一个线程，run可以启动线程吗

https://blog.csdn.net/qq_18738333/article/details/70034919
实际上这两种启动线程的方式原理是一样的。首先都是调用本地方法启动一个线程，其次是在这个线程里执行目标对象的run()方法。那么这个目标对象是什么呢？为了弄明白这个问题，我们来看看Thread类的run()方法的实现：

当我们采用实现Runnable接口的方式来实现线程的情况下，在调用new Thread(Runnable target)构造器时，将实现Runnable接口的类的实例设置成了线程要执行的主体所属的目标对象target，当线程启动时，这个实例的 run()方法就被执行了。

当我们采用继承Thread的方式实现线程时，线程的这个run()方法被重写了，所以当线程启动时，执行的是这个对象自身的 run()方法。

总结起来就一句话，如果我们采用的是继承Thread类的方式，那么这个target就是线程对象自身，如果我们采用的是实现Runnable接口的方式，那么这个target就是实现了Runnable接口的类的实例。

linkedhashmap的结构是怎么样的？

HashMap 是 Java Collection Framework 的重要成员，也是Map族(如下图所示)中我们最为常用的一种。不过遗憾的是，HashMap是无序的，也就是说，迭代HashMap所得到的元素顺序并不是它们最初放置到HashMap的顺序。HashMap的这一缺点往往会造成诸多不便，因为在有些场景中，我们确需要用到一个可以保持插入顺序的Map。庆幸的是，JDK为我们解决了这个问题，它为HashMap提供了一个子类 —— LinkedHashMap。虽然LinkedHashMap增加了时间和空间上的开销，但是它通过维护一个额外的双向链表保证了迭代顺序。特别地，该迭代顺序可以是插入顺序，也可以是访问顺序。因此，根据链表中元素的顺序可以将LinkedHashMap分为：保持插入顺序的LinkedHashMap 和保持访问顺序的LinkedHashMap，其中LinkedHashMap的默认实现是按插入顺序排序的。

本质上，HashMap和双向链表合二为一即是LinkedHashMap。所谓LinkedHashMap，其落脚点在HashMap，因此更准确地说，它是一个将所有Entry节点链入一个双向链表双向链表的HashMap。在LinkedHashMapMap中，所有put进来的Entry都保存在如下面第一个图所示的哈希表中，但由于它又额外定义了一个以head为头结点的双向链表(如下面第二个图所示)，因此对于每次put进来Entry，除了将其保存到哈希表中对应的位置上之外，还会将其插入到双向链表的尾部。

hashmap与hashtable的区别

3 继承的父类不同
4 对外提供的接口不同
5 对Null key 和Null value的支持不同
Hashtable既不支持Null key也不支持Null value
HashMap中，null可以作为键，这样的键只有一个；可以有一个或多个键所对应的值为null。当get()方法返回null值时，可能是 HashMap中没有该键，也可能使该键所对应的值为null。因此，在HashMap中不能由get()方法来判断HashMap中是否存在某个键，而应该用containsKey()方法来判断。
6 线程安全性不同
Hashtable是线程安全的，它的每个方法中都加入了Synchronize方法。在多线程并发的环境下，可以直接使用Hashtable，不需要自己为它的方法实现同步

HashMap不是线程安全的，在多线程并发的环境下，可能会产生死锁等问题。具体的原因在下一篇文章中会详细进行分析。使用HashMap时就必须要自己增加同步处理，

虽然HashMap不是线程安全的，但是它的效率会比Hashtable要好很多。这样设计是合理的。在我们的日常使用当中，大部分时间是单线程操作的。HashMap把这部分操作解放出来了。当需要多线程操作的时候可以使用线程安全的ConcurrentHashMap。ConcurrentHashMap虽然也是线程安全的，但是它的效率比Hashtable要高好多倍。因为ConcurrentHashMap使用了分段锁，并不对整个数据进行锁定。
HashMap的工作原理 http://www.importnew.com/7099.html
HashMap和HashSet的区别 http://www.importnew.com/6931.html
Hashtable和ConcurrentHashMap有什么分别呢？它们都可以用于多线程的环境，但是当Hashtable的大小增加到一定的时候，性能会急剧下降，因为迭代时需要被锁定很长的时间。因为ConcurrentHashMap引入了分割(segmentation)，不论它变得多么大，仅仅需要锁定map的某个部分，而其它的线程不需要等到迭代完成才能访问map。简而言之，在迭代的过程中，ConcurrentHashMap仅仅锁定map的某个部分，而Hashtable则会锁定整个map。
在这里，我们提到了两个非常重要的参数：初始容量和负载因子，这两个参数是影响HashMap性能的重要参数。其中，容量表示哈希表中桶的数量 (table 数组的大小)，初始容量是创建哈希表时桶的数量；负载因子是哈希表在其容量自动增加之前可以达到多满的一种尺度，它衡量的是一个散列表的空间的使用程度，负载因子越大表示散列表的装填程度越高，反之愈小。

　　对于使用拉链法（下文会提到）的哈希表来说，查找一个元素的平均时间是 O(1+a)，a 指的是链的长度，是一个常数。特别地，若负载因子越大，那么对空间的利用更充分，但查找效率的也就越低；若负载因子越小，那么哈希表的数据将越稀疏，对空间造成的浪费也就越严重。系统默认负载因子为 0.75，这是时间和空间成本上一种折衷，一般情况下我们是无需修改的。
https://blog.csdn.net/justloveyou_/article/details/62893086

如果两个对象的hashCode不同，那么equals一定为 false；否则，如果其hashCode相同，equals也不一定为 true。
https://blog.csdn.net/justloveyou_/article/details/71713781

Java 中的 ==, equals 与 hashCode 的区别与联系

https://blog.csdn.net/justloveyou_/article/details/52464440

手写算法，找出二叉树根节点到目标节点的路径

treemap怎么实现的，和hashmap有什么区别，他们是线程安全的吗，如何保证线程安全？

https://blog.csdn.net/qq_24597661/article/details/62042733

concurrenthashmap一定可以保证线程安全吗，为什么？

ConcurrentHashMap是一个双层哈希表。在一个总的哈希表下面，有若干个子哈希表。（这样的双层结构，类似于数据库水平拆分来理解）

ConcurrentHashMap如此的设计，优势主要在于：
每个segment的读写是高度自治的，segment之间互不影响。这称之为“锁分段技术”；

https://blog.csdn.net/qq_24597661/article/details/62042733

osi七层网络，tcp四层网络结构

OSI七层协议模型主要是：应用层（Application）、表示层（Presentation）、会话层（Session）、传输层（Transport）、网络层（Network）、数据链路层（Data Link）、物理层（Physical）。
TCP/IP是一个四层的体系结构，主要包括：应用层、运输层、网际层和网络接口层。从实质上讲，只有上边三层，网络接口层没有什么具体的内容。
https://www.cnblogs.com/wxd0108/p/7597216.html