如果有503错误码的话,就是一个请求网址的服务器建立连接的超时时间超时的问题。如果出现超时的话会抛出一个异常。你可以catch超时异常,然后根据需要处理就行了。
js,建立一个 temp 数组来保存请求的记录,每一个调用 ajax 请求前都保存好必要信息:id(请求标识,标识不同的请求),url,data,callback,reloadtimes(重复请求次数) 。
实际就是消息队列如何保证幂等性
数据库中出现脏数据
( 1)比如你拿个数据要写库,你先根据主键查一下,如果这数据都有了,你就别插入了,update一下好吧
(2)比如你是写redis,那没问题了,反正每次都是set,天然幂等性
(3)比如你不是上面两个场景,那做的稍微复杂一点,你需要让生产者发送每条数据的时候,里面加一个全局唯一的id,类似订单id之类的东西,然后你这里消费到了之后,先根据这个id去比如redis里查一下,之前消费过吗?如果没有消费过,你就处理,然后这个id写redis。如果消费过了,那你就别处理了,保证别重复处理相同的消息即可。
只要保证互斥就行了,原理和单机是一样的,找到一个互斥点就行。那么这个互斥点就必须在大家共有的一个环境中。
1.基于数据库。
2.基于缓存环境,redis,memcache等。
3.基于zookeeper。
redis分布式锁,其实需要自己不断去尝试获取锁,比较消耗性能
zk分布式锁,获取不到锁,注册个监听器即可,不需要不断主动尝试获取锁,性能开销较小
锁是一个很重要也很基础的概念,锁可以看成是多线程情况下访问共享资源的一种线程同步机制。这是对于单进程应用而言的,即所有线程都在同一个JVM进程里的时候,使用Java语言提供的锁 机制可以起到对共享资源进行同步的作用。
redis分布式锁实现的话,setnx和expire命令,如果A线程将expire操作操作到了B线程了,也就是expire了另一个线程的资源,这种怎么避免?
thread pool 种多线程处理形式,维护了很多的很多线程,当程序启动,就开启了大量的线程去等待执行,让cpu进行调度进行任务处理,处理完之后线程并不会被销毁,而是等待下一个任务。由于创建和销毁线程都是消耗系统资源的,所以当你想要频繁的创建和销毁线程的时候就可以考虑使用线程池来提升系统的性能
它是callable创建线程池Executors里的对象,使用 Future 我们可以得知 Callable 的运行状态, 以及获取 Callable 执行完后的返回值
如果线程没有超过20个,那会在开启一个线程执行任务,如果线程超过核心的20个,会进入线程队列中,等待执行,如果不超过最大40个,会启动非核心进程执行,超过最大值,
拒绝执行此任务.ThreadPoolExecutor会通过RejectedExecutionHandler,抛出RejectExecutionException异常.
LinkedBlockingQueue
SynchronousQueue
DelayedWorkQueue
内部元素并不是按照放入的时间排序,而是会按照延迟的时间长短对任务进行排序,内部采用的是“堆”的数据结构(堆的应用之一就是 优先级队列)
LinkedBlockingQueue是一个线程安全的队列,它是一个底层基于链表实现的无界队列,当指定队列容量时,它是一个有界队列。 在LinkedBlockingQueue中,取元素和存元素使用的是两把锁,锁的类型是ReentrantLock。它通过使用Condition的等待/通知来实现了生产者-消费者模型。
由于LinkedBlockingQueue中存元素和取元素使用的是两把锁,存取操作可以同时进行,因此它的吞吐量高于ArrayBlockingQueue。
锁是保存在对象头里面的,根据对象头数据来标识是否有线程获得锁/争抢锁;ReentrantLock锁的是线程,根据进入的线程和int类型的state标识锁的获得/争抢。
之前提到锁(如Mutex和ReentrantLock)基本都是排他锁,这些锁在同一时刻只允许一个线程进行访问。而读写锁(ReadWriteLock)在同一时刻可以允许多个读线程访问,但是在写线程访问时,所有的读线程和其他写线程均被阻塞。
1、http协议:是超文本传输协议,信息是明文传输。如果攻击者截取了Web浏览器和网站服务器之间的传输报文,就可以直接读懂其中的信息。端口 80
2、https协议:是具有安全性的ssl加密传输协议,为浏览器和服务器之间的通信加密,确保数据传输的安全。端口443
对称加密密钥是同一个,非对称加密有公有密钥和私有密钥 非对称加密
数据结构来说:B+树索引,hash索引,FULLTEXT索引,
从物理存储角度
1、聚集索引(clustered index)
2、非聚集索引(non-clustered index)
逻辑上来说:普通索引,唯一索引,全文索引
.B+树的所有数据都存放在叶子节点上
2.B+树的叶子节点之间通过链表的形式相连
3.B+树的非叶子节点只存下一个节点的指针,而B树的非叶子节点不光存指针还要存数据
正式因为B+树的这三个特性,使得在查找时效率比B树要高,所以Innodb的索引的底层数据结构才会使用B+树来实现。
innodb索引底层数据结构就是B+tree
查询条件中没有出现联合索引的第一列,而出现联合索引的第二列,或者第三列,都不会利用联合索引查询
联合索引的最左前缀匹配指的是where条件一定要有联合索引的第一个字段
提交读,未提交读,可重复读,串行读
隔离级别的话是体现事务的隔离性和会出现的问题
事例:程序员某一天去消费,花了2千元,然后他的妻子去查看他今天的消费记录(全表扫描FTS,妻子事务开启),看到确实是花了2千元,就在这个时候,程序员花了1万买了一部电脑,即新增INSERT了一条消费记录,并提交。当妻子打印程序员的消费记录清单时(妻子事务提交),发现花了1.2万元,似乎出现了幻觉,这就是幻读。
不能,Repeatable Read
然后为什么要维持这个特性?因为jdk基于这个特性,实现了HashMap或HashSet等类,key在使用之前都经过hashcode,所以,假如一个类只重写equals方法,创建了两个对象字段一致(equals返回true),而hashcode没有重写,默认根据内存地址来计算,所以两者不一致。 而HashMap或者HashSet里面判断元素相等会用hash值来做判断,这就和equals方法返回的结果不一致,也就造成了逻辑上的错误。其中一个例子就是:使用key的时候是会先对key做hash,然后再做处理,那两个equal的对象作为key,可能会得到不一致的效果。
特殊说明: 解决问题的光鲜,藏着磕Bug的痛苦。 万物皆入轮回,谁也躲不掉! 以上文章,均是我实际操作,写出来的笔记资料,不会出现全文盗用别人文章!烦请各位,请勿直接盗用!