数据库系统

转自： https://www.cnblogs.com/rjzheng/p/9096228.html 引言 为什么写这篇文章? 博主的 《分布式之消息队列复习精讲》 得到了大家的好评，内心诚惶诚恐，想着再出一篇关于复习精讲的文章。但是还是要说明一下，复习精讲的文章偏面试准备，真正在开发过程中，还是脚踏实地，一步一个脚印，不要投机取巧。 考虑到绝大部分写业务的程序员，在实际开发中使用redis的时候，只会setvalue和getvalue两个操作，对redis整体缺乏一个认知。又恰逢博主某个同事下周要去培训redis，所以博主斗胆以redis为题材，对redis常见问题做一个总结，希望能够弥补大家的知识盲点。 复习要点? 本文围绕以下几点进行阐述 1、为什么使用redis 2、使用redis有什么缺点 3、单线程的redis为什么这么快 4、redis的数据类型，以及每种数据类型的使用场景 5、redis的过期策略以及内存淘汰机制 6、redis和数据库双写一致性问题 7、如何应对缓存穿透和缓存雪崩问题 8、如何解决redis的并发竞争问题 正文 1、为什么使用redis 分析 :博主觉得在项目中使用redis，主要是从两个角度去考虑: 性能 和 并发 。当然，redis还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件(如zookpeer等

一 什么是事务？有什么用？ 事务的特性ACID 事务提供了一种机制，可用来将一系列数据库更改归入一个逻辑操作。更改数据库后，所做的更改可以作为一个单元进行提交或取消。事务可确保遵循原子性、一致性、隔离性和持续性（ACID）这几种属性，以使数据能够正确地提交到数据库中。 1）原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作 要么都发生，要么都不发生。 2）一致性（Consistency）一个事务中，事务前后数据的完整性必须保持一致。 3）隔离性（Isolation）多个事务，事务的隔离性是指多个用户并发访问数据库时， 一个用户的 事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。 4）持久性（Durability）持久性是指一个事务一旦被提交，它对数据库中数据的改变 就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。 二 事务的并发会产生的问题有哪些 1.脏读 一个事务正在对数据进行更新操作，但是更新还未提交，另一个事务这时也来操作这组数据，并且读取了前一个事务还未提交的数据，而前一个事务如果操作失败进行了回滚，后一个事务读取的就是错误的数据，这样就造成了脏读 2.不可重复读 一个事务多次读取同一个数据，在该事务还未结束时，另一个事务也对该数据进行 了操作，而且在第一个事务两次读取之间，第二个事务对数据进行了更新，那么第一个

NoSQL技术使用场景: 在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。 为了克服上述的问题，项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。 来源： https://www.cnblogs.com/macT/p/11770717.html

DevOps （Development和Operations的组合词）是一组过程，方法和系统统称，用于促进开发，运维和 QA 之间的沟通，协作和整合。DevOps可以看作是三者的交集。 实现DevOps的工具： 代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion 构建工具：Ant、Gradle、maven 自动部署：Capistrano、CodeDeploy 持续集成（CI）：Bamboo、Hudson、Jenkins 配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail 容器： Docker 、LXC、第三方厂商如AWS 编排：Kubernetes、Core、Apache Mesos、DC/OS 服务注册与发现： Zookeeper 、etcd、Consul 脚本语言：python、ruby、shell 日志管理：ELK、Logentries 系统监控：Datadog、Graphite、Icinga、Nagios 性能监控：AppDynamics、New Relic、Splunk 压力测试：JMeter、Blaze Meter、loader.io 预警：PagerDuty、pingdom、厂商自带如AWS SNS HTTP加速器：Varnish 消息总线：ActiveMQ、SQS

文章目录 Redis知识点总结 1.Redis是什么？都有哪些使用场景？ 2.Redis有哪些功能？ 3.Redis和 memecache 有什么区别？ 4.Redis为什么是单线程的？ 5.什么是缓存穿透？怎么解决？ 6.Redis支持的数据类型有哪些？ 7.Redis支持的 java 客户端都有哪些？ 8.jedis 和 redisson 有哪些区别？ 9.怎么保证缓存和数据库数据的一致性？ 10.Redis持久化有几种方式？ RDB快照 AOF diskstore方式 11.Redis怎么实现分布式锁？ 12.Redis分布式锁有什么缺陷？ 13.Redis如何做内存优化？ 14.Redis淘汰策略有哪些？ 15.Redis常见的性能问题有哪些？该如何解决？ Master写内存快照 Master AOF持久化 Master调用BGREWRITEAOF Redis主从复制的性能问题 总结 16. 缓存预热 17. 缓存更新 18. 缓存降级 Redis知识点总结 1.Redis是什么？都有哪些使用场景？ Redis 是一个key-value存储系统，为了解决应用服务器减少IO读操作，减轻IO压力。大部分情况下是因为其高性能的特性，被当做缓存使用。但是不支持需要事务操作和基于SQL结构化的复杂查询。 **使用场景：**配合关系型数据库作为缓冲、缓冲高频次访问的数据，降低数据库IO

一、使用场景： 1、需要开放ERP数据给第三方系统对接，如APP手机端开发，MES，OA等； 2、接口按现在主流开发，restful风格，传JSON数据，跨平台，不限开发工具； 3、不限易飞ERP，支持大部分主流数据库，包括Microsoft SQL Server、Oracle、MySQL、MariaDB、PostgreSQL、DB2、SQL Anywhere、Firebird、SQLite等 二、优点 ： 1、只要会SQL就可以开放需要的数据，不需要编程基础。如图： ​ 三、测试DEMO： 下载地址： 点击 。 ​ ​ 来源： https://www.cnblogs.com/redhat588/p/11769392.html

关于分布式事务，工程领域主要讨论的是强一致性和最终一致性的解决方案。典型方案包括： 两阶段提交（2PC, Two-phase Commit）方案 eBay 事件队列方案 TCC 补偿模式 缓存数据最终一致性 一、一致性理论 分布式事务的目的是保障分库数据一致性，而跨库事务会遇到各种不可控制的问题，如个别节点永久性宕机，像单机事务一样的ACID是无法奢望的。另外，业界著名的CAP理论也告诉我们，对分布式系统，需要将数据一致性和系统可用性、分区容忍性放在天平上一起考虑。 两阶段提交协议（简称2PC）是实现分布式事务较为经典的方案，但2PC 的可扩展性很差，在分布式架构下应用代价较大，eBay 架构师Dan Pritchett 提出了BASE 理论，用于解决大规模分布式系统下的数据一致性问题。BASE 理论告诉我们：可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。 1、CAP理论 在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。 <img src="https://pic4.zhimg.com/v2-8bb62ba9e7ce9f35199da032e17f9bb7_b.png" data-rawwidth=

业务数据中数据缓存是怎样设计的 ？并发及异步处理怎么实现的？（简述数据穿透及异步操作） 缓存穿透、缓存并发、热点缓存之最佳招式 2018年06月20日 16:29:59 一、前言 我们在用缓存的时候，不管是Redis或者Memcached，基本上会通用遇到以下三个问题： 缓存穿透 缓存并发 缓存失效 缓存穿透 img img img 注： 上面三个图会有什么问题呢？ 我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。那这种问题有什么好办法解决呢？ 要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 有一个比较巧妙的作法是，可以将这个不存在的key预先设定一个值。 比如，”key” , “&&”。 在返回这个&&值的时候，我们的应用就可以认为这是不存在的key，那我们的应用就可以决定是否继续等待继续访问，还是放弃掉这次操作。如果继续等待访问，过一个时间轮询点后，再次请求这个key，如果取到的值不再是&&，则可以认为这时候key有值了，从而避免了透传到数据库，从而把大量的类似请求挡在了缓存之中。 缓存并发 有时候如果网站并发访问高，一个缓存如果失效

在大型系统中（性能要求不高，安全要求高），最好使用外键（外键可以增强数据库数据的完整性和一致性） 在大型系统中（性能要求高，安全自己控制），不用外键（有外键约束的话，插入字段会进行检查，影响效率） 小系统，最好用外键 用外键要适当，不能过分追求 不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后具体应用通过这个层来访问数据库（比如外键约束都转交给dao层） 文章来源: 数据库到底需不需要设置外键？

启动MongoDB有2种方式，一是直接指定配置参数，二是指定配置文件。这里先介绍配置文件，启动方式如下： mongod --config /etc/mongodb.conf 配置如下： verbose ：日志信息冗余。默认false。提高内部报告标准输出或记录到 logpath 配置的日志文件中。要启用verbose或启用 用vvvv参数，如： verbose = true vvvv = true ps：启动verbose冗长信息，它的级别有 vv~vvvvv，v越多级别越高，在日志文件中记录的信息越详细。 port ：端口。默认27017，MongoDB的默认服务TCP端口，监听客户端连接。要是端口设置小于1024，比如1021，则需要root权限启动，不能用mongodb帐号启动，（普通帐号即使是27017也起不来）否则报错：[mongo --port=1021 连接] ERROR: listen(): bind() failed errno: 13 Permission denied for socket: 127.0 . 0.1 : 1021 port = 27017 bind_ip ：绑定地址。默认127.0.0.1，只能通过本地连接。进程绑定和监听来自这个地址上的应用连接。要是需要给其他服务器连接，则需要注释掉这个或则把IP改成本机地址，如192.168.200.201