1. 理解同步和异步
同步:一件事一件事的做,做这件事的时候,不能干其他事情
异步:做一件事的同时,可以做其他事情。很多事情可以同时进行
2. 脏数据
当一个事务正在操作数据库时,数据还没有提交,这时,另外一个事务也访问了这个数据库,然后使用了这个数据,由于访问的并不是最新的数据,那么这个读取的操作可能是不正确的,读到的这个数据就是“脏数据”。
3. 同步(synchronized)处理并发
在方法名前面加上synchronized关键字,或者使用同步锁lock,即可实现同步。
原理:当A事务在处理这件事情的时候,其他的事务只能等待A事务处理完了才能进行处理。
优点:能简单快速的处理并发问题
缺点:
1. 在单机中:由于A事务在进行,其他很多事务都要排队等待,必将使得执行速度变慢,损耗性能。
2. 在分布式中:单个程序中事务的同步并不能使其他的程序事务进行等待,起不到应有的作用。
4. 悲观锁和乐观锁(针对于数据库)
悲观锁:锁定数据库中当前事务要操作的数据,在该数据操作完成后,其他操作才能对数据库进行访问。
实现方法:在sql后面加上 for update或者for update nowait
for update和for update nowait区别:
1. for update 锁定当前操作数据,其他事务等待
2. for update nowait锁定当前数据,其他事务发现数据被锁定,立即返回"ORA-00054错误,内容是资源正忙, 但指定以 NOWAIT 方式获取资源"
例如:select * from account where name="何红乾" for update
优点:无论是在单机还是分布式中,只要使用的是同一个数据库,那么悲观锁就能起到作用。
缺点:锁定数据后,必将影响其他操作,在大流量的情况下,操作速度变慢
乐观锁: 采取版本控制方法,只有当要修改的数据版本高于目前存储的数据版本时,才能操作。
实现方法:在表中增加一个字段version,查询表中数据时,获取version版本号,版本号+1,修改表中数据时核对version版本号是否大于存储的版本号,如果是则操作成功,否则失败。
优点:可以多个事务同时进行,然后根据返回的不同结果做相应的操作,避免了长事务中的数据库加锁开销。
缺点: 乐观锁机制往往基于系统中的数据存储逻辑,因此也具备一定的局 限性,如在上例中,由于乐观锁机制是在我们的系统中实现,来自外部系统的用户 余额更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。在 系统设计阶段,我们应该充分考虑到这些情况出现的可能性,并进行相应调整(如 将乐观锁策略在数据库存储过程中实
现,对外只开放基于此存储过程的数据更新途 径,而不是将数据库表直接对外公开)
5. redis缓存
1. redis不同于mysql,它是完全基于内存的,绝大部分请求是纯粹的内存操作,非常快速。数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1);
2. 数据结构简单,对数据操作也简单,Redis中的数据结构是专门进行设计的;
3. 采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗;
4. 使用多路I/O复用模型,非阻塞IO;
多路I/O复用模型:多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力,在空闲的时候,会把当前线程阻塞掉,当有一个或多个流有 I/O 事件时,就从阻塞态中唤醒,于是程序就会轮询一遍所有的流(epoll 是只轮询那些真正发出了事件的流),并且只依次顺序的处理就绪的流,这种做法就避免了大量的无用操作。
这里“多路”指的是多个网络连接,“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络 IO 的时间消耗),且 Redis 在内存中操作数据的速度非常快,也就是说内存内的操作不会成为影响Redis性能的瓶颈,主要由以上几点造就了 Redis 具有很高的吞吐量
5. 使用底层模型不同,它们之间底层实现方式以及与客户端之间通信的应用协议不一样,Redis直接自己构建了VM 机制 ,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求;
6. redis分布式锁(基于setnx(),expire()方法)
setnx(key,value),如果key不存在,则设置key-value成功,返回1;如果key存在,则返回0。
expire()设置过期时间
实现方法:
1. setnx(lockkey, 1) 如果返回 0,则说明占位失败;如果返回 1,则说明占位成功
2. expire() 命令对 lockkey 设置超时时间,为的是避免死锁问题。
3. 执行完业务代码后,可以通过 delete 命令删除 key。
优点:简单易实现,能解决日常工作需求。
缺点: 如果执行完setnx()方法后,在expire()方法执行前发生了宕机,那么就会出现死锁。
7. redis分布式锁(基于setnx(),get(),getset()方法)
get(key),获取key对应的value。
getset(key,value1),返回null此时key的值会被设置为value1.
getset(key,value2), 返回null此时key的值会被设置为value2.
实现方法:
1. setnx(lockkey, 当前时间+过期超时时间),如果返回 1,则获取锁成功;如果返回 0 则没有获取到锁,则进行其他操作
2. get(lockkey) 获取值 oldExpireTime ,并将这个 value 值与当前的系统时间进行比较,如果小于当前系统时间,则认为这个锁已经超时,可以允许别的请求重新获取,进行其他操作。
3. 计算 newExpireTime = 当前时间+过期超时时间,然后 getset(lockkey, newExpireTime) 会返回当前 lockkey 的值currentExpireTime。
4. 判断 currentExpireTime 与 oldExpireTime 是否相等,如果相等,说明当前 getset 设置成功,获取到了锁。如果不相等,说明这个锁又被别的请求获取走了,那么当前请求可以直接返回失败,或者继续重试。
5. 在获取到锁之后,当前线程可以开始自己的业务处理,当处理完毕后,比较自己的处理时间和对于锁设置的超时时间,如果小于锁设置的超时时间,则直接执行 delete 释放锁;如果大于锁设置的超时时间,则不需要再锁进行处理。
优点:能够防止setnx(),expire()方式出现的死锁问题
缺点: 不太清楚