摘要:应用分布式锁编写一个简单的分布式锁,要求支持超时时间参数注意下方括号的范围
(一)MySQL基础考点 1.事务的原理 特性及并发控制 什么是事务(Transaction)?
事务是数据库并发控制的基本单位 事务可以看作是一些列SQL语句的集合 事务必须要么全部执行成功,要么全部执行失败(回滚) 事务使用常见的场景:银行转账操作事务的ACID特性
原子性(Atomicity):一个事务中所有操作全部完成或失败 一致性(Consistency):事务开始和结束之后数据完整性没有被破坏 隔离性(Isolation):允许多个事务同时对数据库修改和读写 持久性(Durability):事务结束之后,修改是永久的不会被丢失事务并发控制
幻读:一个事务第二次查出现第一次没有的结果 非重复读:一个事务重复读两次得到不同的结果 脏读:一个事务读取到另一个事务没有提交的修改 丢失修改:并发写入造成其中一些修改丢失
读未提交:别的事务可以读取到未提交改变 读已提交:只能读取已经提交的数据 可重复读:同一个事务先后查询结果一样(Mysql innoDB默认实现可重复读级别) 串行化: 事务完全串行化执行,隔离级别最高,效率最低
使用数据库的唯一索引 使用队列异步写入 使用redis等实现分布式锁
悲观锁:先获取锁再进行操作。一锁二查三更新 select for update 乐观锁:先修改,更近的时候发现数据已经变了就回滚(check and set) 使用需要根据响应速度、冲突频率、重试代价来判断使用哪一种
CHAR VARCHAR TINYTEXT TEXT数值型
TINYINT SMALLINT INT SIGINT FLOAT DOUBLE日期和时间
DATE DATETIME TIMESTAMP (4个字节,但接受的时间1970-2038年之间)
MyISAM不支持事务,InnoDB支持事务 MyISAM不支持外键,InnoDB支持外键 MyISAM只支持表锁,InnoDB支持行锁和表锁 MyISAM支持全文索引,InnoDB不支持
数据表种一个或者多个列进行排序的数据结构 索引能够大幅提升索引速度 创建、更新索引本身也会消耗空间和时间什么是B-Tree?(查找结构进化史)
多路平衡查找树B+Tree
Mysql实际使用的B+Tree作为索引的数据结构
普通索引 CREATE INDEX 唯一索引,索引列的值必须唯一 CREATE UNIQUE INDEX 多列索引(联合索引) 主键索引 一个表只能有一个 PRIMARY KEY 全文索引 InnoDB不支持(一般采用专门的全文索引数据库实现)什么时候创建索引?(建表的时候需要根据查询需求来创建索引)
经常用作查询条件的字段(WHERE条件) 经常用作表连接的字段 经常出现在order by, group by之后的字段创建索引有哪些需要注意的?(最佳实践)
非空字段NOT NULL, Mysql很难对空值做查询优化 区分度高,离散度大,作为索引的字段值尽量不要有大量相同值 索引的长度不要太大(比较消耗时间--索引作为B+Tree的key值存在,字符串key太长比较耗时)索引什么时候失效?
记忆口诀:模型匹配、类型隐转、最左匹配 以%开头的LIKE语句,模糊搜索 出现隐式转换(python这种动态语言查询中需要注意) 没有满足最左前缀原理(针对联合索引)什么聚集索引和非聚集索引
是指B+Tree叶节点存的是指针还是数据记录 MyISAM索引和数据分离,使用的是非聚集索引(存的是数据指针) InnoDB数据文件就是索引文件,主键索引就是聚集索引
slow_query_log_file开启并且查询慢查询日志 通过explain命令排查索引问题 调整数据修改索引;业务代码层限制不合理访问(比如一次获取太多数据--实现分页; 数据类型不匹配导致全文扫描)
内连接(INNER JOIN):两个表都存在匹配时,才会返回匹配行 外连接(LEFT/RIGHT JOIN): 返回一个表的行,即使另一个没有匹配 全连接(FULL JOIN):只要某一个表存在匹配就返回
缓解关系数据(常见的Mysql)并发访问的压力: 热点数据 减少响应时间:内存IO速度比磁盘快 提升吞吐量: Redis等内存数据库单机就可以支持很大并发Redis和Memcached主要区别?
数据存储类型:redis支持string/List/hash/set/sort set;memcached只支持文本型/二进制类型 网络IO模型:redis单进程模式;memcached多线程、非阻塞IO模式 持久化支持:redis支持两种RDB,DOF; memcached不支持
String(字符串):用来实现简单的KV键值对存储,比如计数器
List(链表): 实现双向链表,比如用户的关注,粉丝列表
Hash(哈希表):用来存储彼此相关信息的键值对
Set(集合): 存储不重复元素,比如用户的关注者
Sorted set(有序集合): 实时信息排行榜
快照方式:把树快照放在磁盘二进制文件中,dump.rdb AOF: 每一个写命令追加到appendonly.aof中 可以修改通过Redis配置实现什么redis事务?
将多个请求打包,一次性,按序执行多个命令的机制 通过 MULTI, EXEC,WATCH等命令实现事务功能如何实现分布式锁?
使用setnx实现加锁,可以同时通过expire添加超时时间 锁的value值可以使用一个随机的uuid或者特定的命名 释放锁的时候,通过uuid判断是否是该锁,是则执行delete释放锁
Cache Aside: 同时更新缓存和数据库 Read/Write Through: 先更新缓存,缓存负责同步更新数据库 Write Behind Caching: 先更新缓存,缓存定期异步更新数据库如何解决缓存穿透问题?
原因:由于大量缓存查不到就去数据库取,数据库也没有要查的数据 解决:对于没有查到返回None的数据也缓存; 插入数据的时候删除相应缓存,或者设置较短的超时时间如何解决缓存击穿问题?
原因:某些非常热点的数据key过期,大量请求达到后端数据库 解决: 分布式锁-获取锁的线程从数据库拉数据更新缓存,其他线程等待 异步后台更新-后台任务针对过期key自动刷新如何解决缓存雪崩问题?
原因:缓存不可用或大量缓存key同时失效,大量请求直接达到数据库 解决: 多级缓存--不同级别的key设置不同的超时时间 随机超时--key的超时时间随机设置,防止同时超时 架构层--提升系统可用性,监控、报警完善
在最佳实践中,auto_increment字段长度比uuid小,从性能及可读性都比uuid要好如果是分布式系统下我们怎么生成数据库的自增id呢?
在auto_increment的基础上,设置step增长步长;比如:Master1 生成的是 1,4,7,10, Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。 这样就可以有效生成集群中的唯一ID,也可以大大降低ID生成数据库操作的负载。
编写一个简单的分布式锁,要求支持超时时间参数
import time import redis class RedisLock(object): def __init__(self, key, timeout): self.rdcon = redis.Redis(host="", port=6379, password="", db=1) self._lock = 0 self.timeout = timeout self.lock_key = "%s_dynamic_test" % key @staticmethod def get_lock(cls): while cls._lock != 1: timestamp = time.time() + self.timeout + 1 cls._lock = cls.rdcon.setnx(cls.lock_key, timestamp) # 注意下方括号的范围 if cls._lock == 1 or (time.time() > cls.rdcon.get(cls.lock_key) and time.time() > cls.rdcon.getset(cls.lock_key, timestamp)): print "get lock" break else: time.sleep(0.3) @staticmethod def release(cls): if time.time() < cls.rdcon.get(cls.lock_key): print("release lock") cls.rdcon.delete(cls.lock_key) def deco(cls): def _deco(func): def __deco(*args, **kwargs): print("before %s called [%s]."%(func.__name__, cls)) cls.get_lock(cls, timeout) try: return func(*args, **kwargs) finally: cls.release(cls) return __deco return _deco @deco(RedisLock("key")) def myfunc(): # do_something time.sleep(20) if __name__ == "__main__": myfunc()
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/110656.html
摘要:我一直认为运维工程师就是让跳舞的人,当我操纵几百台机器,整齐划一地做一件事情,那种感觉特别棒。技术人攻略你怎么看待,运维和开发的关系应该怎样平衡国内大家提得多 showImg(http://segmentfault.com/img/bVb66I); 技术人攻略:运维工作普遍很辛苦,你却能做得如此快乐,有哪些经验可以分享? 流程比补位更重要,方法比拼命更重要。UPYUN运...
摘要:他希望能传递运维的正能量,就和攻略君一起来看这段运维人的拓荒历程吧技术人攻略能否介绍一下你是如何把嵌入式的思想应用到了运维领域我年进大学开始接触,到年加入台湾威盛之前,已经玩了年。showImg(http://segmentfault.com/img/bVb66I);文:Gracia(本文为原创内容,部分或全文转载均需经过作者授权,并保留完整的作者信息和技术人攻略介绍。) 导语:本期采访对...
摘要:,谷歌给的一份性能指南和最佳实践。目前而言,前端社区有三大框架和。随后重点讲述了和两大前端框架,给出了大量的文章教程和相关资源列表。我认为,使用函数式编程方式,更加符合后端程序员的思路,而是更符合前端工程师习惯的框架。 showImg(https://segmentfault.com/img/bVbjQAM?w=1142&h=640); 这个是我订阅 陈皓老师在极客上的专栏《左耳听风》...
摘要:,谷歌给的一份性能指南和最佳实践。目前而言,前端社区有三大框架和。随后重点讲述了和两大前端框架,给出了大量的文章教程和相关资源列表。我认为,使用函数式编程方式,更加符合后端程序员的思路,而是更符合前端工程师习惯的框架。 showImg(https://segmentfault.com/img/bVbjQAM?w=1142&h=640); 这个是我订阅 陈皓老师在极客上的专栏《左耳听风》...
阅读 890·2021-11-24 10:24
阅读 2378·2021-11-22 13:54
阅读 1768·2021-11-11 16:53
阅读 779·2021-09-24 09:55
阅读 3431·2019-08-30 15:54
阅读 1202·2019-08-30 15:44
阅读 968·2019-08-30 14:23
阅读 3099·2019-08-29 13:45