Redis实现的数据库事务机制
Redis是一种高效的键值存储数据库，支持多种数据结构和操作命令，包括事务机制。数据库事务机制确保一组关联的命令在同一事务中一起执行，而且这些命令要么全部执行完成，要么全部不执行。本文探讨Redis实现的数据库事务机制及其应用。
Redis事务机制的原理
Redis通过MULTI、EXEC、DISCARD和WATCH命令实现事务机制。MULTI命令用于开启一个事务，EXEC命令用于提交事务，DISCARD命令用于终止事务，WATCH命令用于监视键的变化情况。可以配合使用多个Redis命令来实现一个事务，只要这些命令都在MULTI和EXEC命令之间执行即可，如下面的示例代码：
MULTISET key1 value1SET key2 value2EXEC
以上代码表示在执行SET key1 value1和SET key2 value2之前开启了一个事务，在EXEC命令之后提交了这个事务。如果其中一个命令执行失败，则整个事务将会回滚。
Redis事务机制的应用
Redis事务机制可以用于批量操作和数据一致性的维护，下面举几个具体例子。
批量操作
如果有多个Redis命令需要执行，而这些命令需要执行完成后再执行其他操作，那么可以开启一个事务，将这些命令放入事务中执行，以保证这些命令按照特定的顺序一起执行完成。例如可以通过以下代码添加多个键值对：
MULTISET key1 value1SET key2 value2SET key3 value3EXEC
数据一致性的维护
在修改Redis中的某些键值对时，需要同时修改多个键值对以保证数据的一致性。例如下面的示例代码：
MULTISET balance 1000SET source_account_balance ($source_account_balance- $transfer_amount)SET target_account_balance ($target_account_balance+ $transfer_amount)EXEC
以上代码表示在银行转账的场景中，开启了一个事务，分别修改余额表和两个账户的余额。在事务提交之前如果任何一个命令执行失败，整个事务将会回滚，保证数据的一致性。
WATCH命令
除了MULTI、EXEC和DISCARD命令之外，Redis的事务机制还支持WATCH命令。WATCH命令可以监视一个或多个Redis键，如果这些键在事务执行期间被其他客户端修改，则当前事务将会被回滚。这样就可以确保多个客户端同时对同一个键进行修改时只有一个客户端能够成功执行，其他客户端需要重新尝试修改。例如下面的示例代码：
WATCH key1 key2MULTISET key1 value1SET key2 value2EXEC
以上代码表示在修改key1和key2的值之前先监视这两个键，保证在事务执行期间这两个键没有被修改，如果被修改则事务会自动回滚。
结论
Redis的事务机制通过MULTI、EXEC、DISCARD和WATCH命令实现，支持批量操作和数据一致性的维护，是保证数据的强一致性和高并发访问的重要工具之一。适当运用Redis的事务机制能够提高系统的性能和运行稳定性。
香港服务器首选树叶云，2H2G首月10元开通。树叶云（www.IDC.Net）提供简单好用，价格厚道的香港/美国云 服务器 和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。
电子支票是什么东西？
电子支票是一种借鉴纸张支票转移支付的优点，利用数字传递将钱款从一个帐户转移到另一个帐户的电子付款形式。 这种电子支票的支付是在与商户及银行相连的网络上以密码方式传递的，多数使用公用关键字加密签名或个人身份证号码(PIN)代替手写签名。 用电子支票支付，事务处理费用较低，而且银行也能为参与电子商务的商户提供标准化的资金信息，故而可能是最有效率的支付手段。 使用电子支票进行支付，消费者可以通过电脑网络将电子支票发向商家的电子信箱，同时把电子付款通知单发到银行，银行随即把款项转入商家的银行帐户。 这一支付过程在数秒内即可实现。 然而，这里面也存在一个问题，那就是：如何鉴定电子支票及电子支票使用者的真伪？因此，就需要有一个专门的验证机构来对此作出认证，同时，该验证机构 还应像CA那样能够对商家的身份和资信提供认证。 电子支票交易的过程可以分以下几个步骤： （1）消费者和商家达成购销协议并选择用电子支票支付。 （2）消费者通过网络向商家发出电子支票，同时向银行发出付款通知单。 （3）商家通过验证中心对消费者提供的电子支票进行验证，验证无误后将电子支票送交银行索付。 （4）银行在商家索付时通过验证中心对消费者提供的电子支票进行验证，验证无误后即向商家兑付或转帐。
sql2005 数据库快照是什么？
数据库快照是MSSQL2005的新功能，仅在 Microsoft SQL Server 2005 Enterprise Edition 中可用。 而且SQL Server Management Studio 不支持创建数据库快照，创建快照的唯一方式是使用 Transact-SQL。 数据库快照是数据库（称为“源数据库”）的只读静态视图。 在创建时，每个数据库快照在事务上都与源数据库一致。 在创建数据库快照时，源数据库通常会有打开的事务。 在快照可以使用之前，打开的事务会回滚以使数据库快照在事务上取得一致。 客户端可以查询数据库快照，这对于基于创建快照时的数据编写报表是很有用的。 而且，如果以后源数据库损坏了，便可以将源数据库恢复到它在创建快照时的状态。 创建数据库快照可以： ·维护历史数据以生成报表。 可以通过快照访问特定时间点的数据。 例如，您可以在给定时间段（例如，财务季度）要结束的时候创建数据库快照以便日后制作报表。 然后便可以在快照上运行期间要结束时创建的报表。 ·将查询实施在数据库的快照上，可以释放主体数据库上的资源。 ·加快恢复操作效率，使用快照将数据库恢复到生成快照时的状态比从备份还原快得多；但是，此后您无法对数据进行前滚操作。 根据磁盘资源，可以每 24 小时创建 6 到 12 个滚动快照。 每创建一个新的快照，就删除最早的快照。 如果要恢复，可以将数据库恢复到在错误发生的前一时刻的快照。 或者，也可以利用快照中的信息，手动重新创建删除的表或其他丢失的数据。 例如，可以将快照中的数据大容量复制到数据库中，然后手动将数据合并回数据库中。 但是只要存在数据库快照，快照的源数据库就存在以下限制： ·必须在与源数据库相同的服务器实例上创建数据库快照。 · 数据库快照捕获开始创建快照的时间点，去掉所有未提交的事务。 未提交的事务将在创建数据库快照期间回滚，因为数据库引擎 将对快照执行恢复操作（数据库中的事务不受影响）。 ·当将源数据库中更新的页强制压入快照时，如果快照用尽磁盘空间或者遇到某些错误，则该快照将成为可疑快照并且必须将其删除。 有关详细信息，请参阅删除数据库快照。 ·快照为只读。 · 禁止对 model 数据库、master 数据库和 tempdb 数据库创建快照。 · 不能更改数据库快照文件的任何规范。 ·不能从快照中删除文件。 ·不能备份或还原快照。 ·不能附加或分离快照。 ·不能在 FAT32 文件系统或 RAW 分区中创建快照。 · 数据库快照不支持全文索引，不能从源数据库传播全文目录。 ·数据库快照将继承快照创建时其源数据库的安全约束。 由于快照是只读的，因此无法更改继承的权限，对源数据库的更改权限将不反映在现有快照中。 ·快照始终反映创建该快照时的文件组状态：在线文件组将保持在线状态，离线文件组将保持离线状态。 有关详细信息，请参阅本主题后面的“含有离线文件组的数据库快照”。 ·如果源数据库的状态为 RECOVERY_PENDING，可能无法访问其数据库快照。 但是，当解决了源数据库的问题之后，快照将再次变成可用快照。 ·只读文件组和压缩文件组不支持恢复。 尝试恢复到这两类文件组将失败。 有关恢复的详细信息，请参阅恢复到数据库快照。
deadlocks（死锁）是什么？
在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁。 例如：事务 A 获取了行 1 的共享锁。 事务 B 获取了行 2 的共享锁。 现在，事务 A 请求行 2 的排他锁，但在事务 B 完成并释放其对行 2 持有的共享锁之前被阻塞。 现在，事务 B 请求行 1 的排他锁，但在事务 A 完成并释放其对行 1 持有的共享锁之前被阻塞。 事务 A 必须在事务 B 完成之后才能完成，但事务 B 被事务 A 阻塞。 这种情况也称为循环依赖关系：事务 A 依赖于事务 B，而事务 B 又依赖于事务 A，从而形成了一个循环。 除非某个外部进程断开死锁，否则死锁中的两个事务都将无限期等待下去。 Microsoft SQL Server Database Engine 死锁监视器定期检查陷入死锁的任务。 如果监视器检测到循环依赖关系，将选择其中一个任务作为牺牲品，然后终止其事务并提示错误。 这样，其他任务就可以完成其事务。 对于事务以错误终止的应用程序，它还可以重试该事务，但通常要等到与它一起陷入死锁的其他事务完成后执行。 在应用程序中使用特定编码约定可以减少应用程序导致死锁的机会。 有关详细信息，请参阅将死锁减至最少。 死锁经常与正常阻塞混淆。 事务请求被其他事务锁定的资源的锁时，发出请求的事务一直等到该锁被释放。 默认情况下，SQL Server 事务不会超时（除非设置了 LOCK_TIMEOUT）。 因为发出请求的事务未执行任何操作来阻塞拥有锁的事务，所以该事务是被阻塞，而不是陷入了死锁。 最后，拥有锁的事务将完成并释放锁，然后发出请求底事务将获取锁并继续执行。 死锁有时称为抱死。 不只是关系数据库管理系统，任何多线程系统上都会发生死锁，并且对于数据库对象的锁之外的资源也会发生死锁。 例如，多线程操作系统中的一个线程要获取一个或多个资源（例如，内存块）。 如果要获取的资源当前为另一线程所拥有，则第一个线程可能必须等待拥有线程释放目标资源。 这就是说，对于该特定资源，等待线程依赖于拥有线程。 在数据库引擎 实例中，当获取非数据库资源（例如，内存或线程）时，会话会死锁。 在上图中，对于 Part 表锁资源，事务 T1 依赖于事务 T2。 同样，对于 Supplier 表锁资源，事务 T2 依赖于事务 T1。 因为这些依赖关系形成了一个循环，所以在事务 T1 和事务 T2 之间存在死锁。
发表评论