本文目录
【必知必会】面对不同的业务场景，如何选择NOSQL和SQL
NoSQL和SQL看上去很像，以至于不少人把两者混为一谈，其实这两者完全是两类东西，虽然在开发中经常看见两者配合使用，但两者的定位不同，服务场景也是不同的。
随着NoSQL数据库的兴起，不少人觉得未来NoSQL会取代传统的数据库，也有人认为NoSQL和SQL最终会融合在一起。未来的事情不好猜测，但在这里我们可以分析下两者的定位。
什么是NoSQL？什么是SQL？
1、NoSQL不能光看字面意思，不能理解为“没有SQL”，其实它是“Not Only SQL”的简称，它是非关系型数据库的统称，它的特点就是：非关系型、半结构化、分布式、无ACID特性。
NoSQL代表有：Redis、MemCache、MongoDB等。
2、SQL本意是指结构化查询语句，它其实是一种特殊的编程语言，是用于关系型数据库的查询语言。只不过现在很多不严谨的开发者将SQL视为数据库的统称。
SQL数据库代表有：MySQL、Orache、SQL Server。
NoSQL与SQL数据库的各自特点
1、NoSQL数据库
存储数据不需要特定的模式；
使用类JSON格式的文档（半结构化）来存储键值对；
没有 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）这4种特性。
NoSQL数据库更适合存储非结构化数据、不确定需求的数据，数据是碎片化的。数据一般是存储在内存中的（个别的支持持久化到硬盘上），操作速度极快。
2、SQL数据库
存储数据前需明确定义字段模式；
使用表来存储结构化的数据；
保证数据的事务性、一致性要求。
关系型数据库更适合存储结构化数据、数据要求严谨，数据模式是固定不变的。数据是存储在硬盘上的，数据量过大时操作速度会受到影响。
NoSQL与SQL数据库如何选择？
在开头时就提及NoSQL与SQL的争议，我更倾向于说未来NoSQL和SQL可能会融合在一起。在如今的技术架构中我们通常也都是这样去搭配使用的：SQL数据库作为最终数据落地存储方案，而NoSQL则用来缓存热点数据，提升数据查询和操作速度。-durability
以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！线上服务宕机时，如何保证数据100%不丢失
我们有很多的手段保证数据的安全，但是要保证100%安全这是不可能的。毕竟在系统运行的过程中，服务器可以出的问题千奇百怪，只能说尽可能的让数据尽可能的出出现丢失。
单纯的保证数据库本身的数据不丢失的话，最直接的方式就是通过建立主从库，实现数据的热备
一般情况下，小的系统我们并不会考虑数据的热备，一般只是在每天定时进行冷备而已，也就是设置一个定时器，然后到时间就同步数据。不过这样做的话，一单系统的数据库出现异常，那么我们的数据就会回滚到上一个备份的时间点，影响范围就会比较大。-durability
因此，对于数据量大一点的系统，我们就会进行主从库的设置，不过通常情况下，我们做了主从库都会做读写分离。
现在不管是哪种数据库，都提供了数据库之间订阅同步的机制。以Mysql为例，我们先设置一个Master主库，然后在基于这个主库设置1个到多个Salve从主，从库通过在主库的SQLLog日志进行监听，一旦有SQL执行，就会记录一个二进制的Log，从库发现了这个Log，也会同时执行同样的操作，这样就实现了数据的热备。-durability
但是，这种热备的机制并不能100%保证数据不丢失。因为，我们在写入主库的时候如果出现异常，导致SQLLog还没有记录，那么从库是不可能有数据记录的。当然，此后的数据不会有影响，因为这是从库会变为主库来记录后续数据。同样，如果主从库一起宕机，那也只有凉凉。-durability
那么，为了让数据库的数据更加安全，就需要把数据保证的机制提前，不能单纯的依靠数据库来实现，那么我们可以加入队列来试试。
队列并不是针对于数据的，队列其实是用来保证消息的安全稳定的。自然，当请求没有被写入到数据库是，都是以消息的形态存在，我们就可以考虑队列来保证数据安全。
在数据库访问层，或者再靠前，到服务层，我们都可以加入MQ，让每一个请求都通过MQ来顺序的处理，一但数据库宕机了，MQ的执行就会失败，这时，失败的记录会被保存在MQ里面，并不会丢失，一但数据库重启，我们可以再次执行MQ中的消息，保证数据被成功的写入到数据库中。-durability
具体怎么做呢？
首先，我们在插入数据库前，把插入的操作变为向队列对添加一个消息，然后，我们不同队列建立不同的消费者，消费者对队列的消息进行执行，再往数据库里面插入数据。
对于我们的服务层，我们只要把消息插入到了队列中，即视为成功，返回成功的消息。这样，虽然我们的数据处理会有一点点的延时，并且在事务的控制上难度会变大，可能需要建立补偿机制，但是我们的数据安全就更加高了。-durability
这样是不是就安全了呢？
并不是的。消息服务器也可能会宕机，消息也有可能出现丢失的情况，所以并不能保证100%的安全。
如果我们还需要做的更好，我们还可以加上MongoDB来做日志
MongoDB是一个非关系型数据库，在我们现在的系统中应用非常广。最多的应用场景就是用来记录日志。那么，日志就是一个帮助我们避免消息丢失的有效方式了。
我们对服务层的每个请求报文，都用MongoDB记录请求的报文，再在请求处理完成返回结果的时候，记录一个消息的处理结果（成功或失败），这样，我们就能够很直观的看到每天发生的请求，处理的请求情况了。
当有服务处理失败了，不管是数据库的问题还是其他的问题，我们都可以对异常进行排查，然后再根据报文进行消息的重推。这样，我们的数据就会更加的安全了。
当然，即使如此，也不可能100%安全的，我们只能说尽可能的让系统更安全，只不过，安全的同时，付出的成功也是高昂的，我们需要来衡量是否有这个必要，当我们的系统确实足够大，用户量很大时，这么处理是有价值的，否则，那就是一种资源的浪费。-durability
