谈一谈如何使用etcd中的事务
本文内容来源于自己学习时所做的记录,主要来源于文章最后的参考链接,如有侵权,请联系删除,谢谢!
etcd 是一个 key/value 类型的数据库。既然我们需要存储数据,必然会面临这样一个需求,即希望无论什么样的场景下,一组操作要么同时完成,要么都失败,哪怕数据库出现了故障,甚至了机器发生了宕机。幸运的是 从 etcd 3.4 版本开始,开始支持事务。
etcd 中的事务,实现了原子地执行冲突检查、更新多个 keys 的值。除此之外,etcd 将底层 MVCC 机制的版本信息暴露出来,基于版本信息封装出了一套基于乐观锁的事务框架 STM,并实现了不同的隔离级别。接下来我们就一起学习学习。
1、什么是事务?
事务(Transaction)是指数据库管理系统中的一个基本操作单位,通常由一组对数据库的读/写操作组成一个不可分割的操作序列。
在关系型数据库中,事务应该具备 ACID
特性,即原子性、一致性、隔离性、持久性。具体解释如下:
- 原子性(Atomicity):事务作为一个不可分割的操作序列,要么全部执行成功,要么全部回滚。如果事务在执行过程中发生错误,需要将已经修改的数据撤销到事务开始前的状态。
- 一致性(Consistency):指事务执行前和执行后的数据状态保持一致。在事务执行过程中,数据库会处于一种中间状态,需要通过在事务结束时进行一些额外的工作来确保数据的一致性。这里理解起来还是有点抽象,我们借助一个例子来说明:
比如,用户 A 和用户 B 在银行分别有 1000 元和 500 元,总共 1500 元,用户 A 给用户 B 转账 200 元,分为两个步骤,从 A 的账户扣除 200 元和对 B 的账户增加 200 元。一致性就是要求上述步骤操作后,最后的结果是用户 A 还有 800 元,用户 B 有 700 元,总共 1500 元,而不会出现用户 A 扣除了 200 元,但用户 B 未增加的情况(该情况,用户 A 为 800 元,用户 B 为500 元,总共 1300 元)。
- 隔离性(Isolation):多个事务并发执行时,每个事务是彼此隔离的,互相不干扰。隔离级别越高,就越能防止出现脏读、不可重复读、幻读等问题。
- 持久性(Durability):指一旦事务提交,则所有修改的数据都将永久保存在数据库中。即使发生系统故障,也不会丢失任何数据。
常见的关系型数据库如 MySQL,在存储引擎为 InnoDB时是支持事务的,那InnoDB 引擎通过什么技术来保证事务的这四个特性的呢?
- 持久性是通过 redo log (重做日志)来保证的;
- 原子性是通过 undo log(回滚日志) 来保证的;
- 隔离性是通过 MVCC(多版本并发控制) 或锁机制来保证的;
- 一致性则是通过持久性+原子性+隔离性来保证;
了解了 MySQL 中的事务的简单实现方式后,接下来讲一讲 etcd 中的事务。
etcd 中的事务则是基于 CAS(Compare and Swap,即比较再交换) 方式
。
etcd 使用了不到四百行的代码实现了迷你事务,其对应的语法为 If-Then-Else
。etcd 允许用户在一次修改中批量执行多个操作,即这一组操作被绑定成一个原子操作,并共享同一个修订号。写法类似 CAS,如下所示:
Txn().If(cond1, cond2, ...).Then(op1, op2, ...,).Else(op1, op2)
上面语句的意思是,如果 If 冲突判断语句为真,对应返回值为 true,Then 中的语句将会被执行,否则执行 else 中的逻辑。
在 etcd 事务执行过程中,客户端与 etcd 服务端之间没有维护事务会话。冲突判断(If)和执行过程 Then/Else
作为一个原子过程来执行 If-Then-Else
,因此 etcd 事务不会发生阻塞,无论成功还是失败都会返回,当发生冲突导致执行失败时,需要应用进行重试。业务代码需要考虑这部分的重试逻辑。
讲了这么多理论的东西,接下来就一起看一看 etcd 中事务的使用案例。
2、etcd中事务的使用案例
这里使用一个比较容易理解的例子来进行演示,用户A 向 用户B 转账的场景。etcd 的事务基于乐观锁
思想,当检测到冲突会发起重试,检测冲突时使用了ModRevision进行校验,该字段表示某个 key 上一次被更改时,全局的版本是多少。因此,我们实现转账业务的流程如下所示:
代码如下:
package main
import (
"context"
"fmt"
clientv3 "go.etcd.io/etcd/client/v3"
"strconv"
"time"
)
func main() {
config := clientv3.Config{
Endpoints: []string{"192.168.91.66:12379"},
DialTimeout: 5 * time.Second,
}
// 建立连接
client, err := clientv3.New(config)
if err != nil {
fmt.Println(err)
return
}
sender, receiver := "/sender_amount", "/receiver_amount"
_, err = client.Put(context.Background(), sender, "1000")
if err != nil {
fmt.Printf("etcd put /sender_amount failed, err:%v\n", err)
return
}
_, err = client.Put(context.Background(), receiver, "500")
if err != nil {
fmt.Printf("etcd put /receiver_amount failed, err:%v\n", err)
return
}
err = txnTransfer(client, sender, receiver, 200)
if err != nil {
fmt.Printf("etcd txnTransfer failed, err:%v\n", err)
return
}
}
func txnTransfer(etcd *clientv3.Client, sender, receiver string, amount uint64) error {
// 失败重试
for {
if ok, err := doTxn(etcd, sender, receiver, amount); err != nil {
return err
} else if ok {
return nil
}
}
}
func doTxn(etcd *clientv3.Client, sender, receiver string, amount uint64) (bool, error) {
// 第一个事务,利用事务的原子性,同时获取发送和接收者的余额以及 ModRevision
getResp, err := etcd.Txn(context.TODO()).Then(clientv3.OpGet(sender), clientv3.OpGet(receiver)).Commit()
if err != nil {
return false, err
}
senderKV := getResp.Responses[0].GetResponseRange().Kvs[0]
receiverKV := getResp.Responses[1].GetResponseRange().Kvs[0]
senderNum, receiverNum := toUInt64(senderKV.Value), toUInt64(receiverKV.Value)
// 验证账户余额是否充足
if senderNum < amount {
return false, fmt.Errorf("资金不足")
}
// 发起转账事务,冲突判断 ModRevision 是否发生变化
txn := etcd.Txn(context.TODO()).If(
clientv3.Compare(clientv3.ModRevision(sender), "=", senderKV.ModRevision),
clientv3.Compare(clientv3.ModRevision(receiver), "=", receiverKV.ModRevision))
// ModRevision 未发生变化,即 If 判断条件成功
txn = txn.Then(
clientv3.OpPut(sender, fromUint64(senderNum-amount)), // 更新发送者账户余额
clientv3.OpPut(receiver, fromUint64(receiverNum+amount))) // 更新接收者账户余额
resp, err := txn.Commit() // 提交事务
if err != nil {
return false, err
}
return resp.Succeeded, nil
}
func toUInt64(value []byte) uint64 {
ret, err := strconv.Atoi(string(value))
if err != nil {
fmt.Printf("value to uint64 failed, err: %v\n", err)
return 0
}
return uint64(ret)
}
func fromUint64(number uint64) string {
return strconv.Itoa(int(number))
}
转账业务开始前,sender、reciver的余额如下:
转账业务完成后,sender、reciver的余额如下:
如上 etcd 事务的实现基于乐观锁
思想,涉及到两次事务操作,第一次事务利用原子性来同时获取发送方和接收方的当前账户金额;第二次事务发起转账操作,冲突检测 ModRevision
是否发生变化,如果没有变化则正常提交事务。若发生了冲突,则需要进行重试。
如上过程的实现较为繁琐,除了业务逻辑,还有大量的代码用来判断冲突以及重试。因此,etcd 社区基于事务特性,实现了一个简单的事务框架 STM,构建了各个事务隔离级别类,下面我们看看基于 STM 框架如何实现 etcd 事务。
3、使用 STM 实现转账
那如何简化 etcd 事务实现的过程呢,etcd clientv3 提供了 STM,即软件事务内存,帮我们自动处理这些繁琐的过程。使用 STM 的转账业务代码如下:
package main
import (
"context"
"fmt"
clientv3 "go.etcd.io/etcd/client/v3"
"go.etcd.io/etcd/client/v3/concurrency"
"strconv"
"time"
)
func main() {
config := clientv3.Config{
Endpoints: []string{"192.168.91.66:12379"},
DialTimeout: 5 * time.Second,
}
// 建立连接
client, err := clientv3.New(config)
if err != nil {
fmt.Println(err)
return
}
sender, receiver := "/sender_amount", "/receiver_amount"
_, err = client.Put(context.Background(), sender, "1000")
if err != nil {
fmt.Printf("etcd put /sender_amount failed, err:%v\n", err)
return
}
_, err = client.Put(context.Background(), receiver, "500")
if err != nil {
fmt.Printf("etcd put /receiver_amount failed, err:%v\n", err)
return
}
err = txnStmTransfer(client, sender, receiver, 200)
if err != nil {
fmt.Printf("etcd txnTransfer failed, err:%v\n", err)
return
}
}
func txnStmTransfer(cli *clientv3.Client, from, to string, amount uint64) error {
// NewSTM 创建了一个原子事务的上下文,并把我们的业务代码作为一个函数传进去
_, err := concurrency.NewSTM(cli, func(stm concurrency.STM) error {
// stm.Get 封装好了事务的读操作
senderNum := toUint64(stm.Get(from))
receiverNum := toUint64(stm.Get(to))
if senderNum < amount {
return fmt.Errorf("余额不足")
}
// stm.Put封装好了事务的写操作
stm.Put(to, fromUint64(receiverNum+amount))
stm.Put(from, fromUint64(senderNum-amount))
return nil
})
return err
}
func toUint64(value string) uint64 {
ret, err := strconv.Atoi(value)
if err != nil {
fmt.Printf("value to toUint64 failed, err: %v\n", err)
return 0
}
return uint64(ret)
}
func fromUint64(number uint64) string {
return strconv.Itoa(int(number))
}
上述基于 STM 实现的转账业务流程,我们只要关注转账逻辑的实现即可,事务相关的其他操作由 STM 完成。
STM 的使用特别简单,只需把业务相关的代码封装成可重入的函数
传给 stm,然后 STM 会处理好其余所有的细节。STM 对象在内部构造 txn 事务,把我们编写的业务函数翻译成 If-Then
,自动提交事务,处理失败重试等工作,直到事务执行成功,或者出现异常,重试亦不能解决。
接下来我们一起初略的看看 NewSTM 的内部做了些什么
// 位于 clientv3/concurrency/stm.go:89
func NewSTM(c *v3.Client, apply func(STM) error, so ...stmOption) (*v3.TxnResponse, error) {
opts := &stmOptions{ctx: c.Ctx()}
for _, f := range so {
f(opts)
}
if len(opts.prefetch) != 0 {
f := apply
apply = func(s STM) error {
s.Get(opts.prefetch...)
return f(s)
}
}
return runSTM(mkSTM(c, opts), apply)
}
根据源码可以知道,NewSTM
首先创建一个 stm,然后执行 stm,代码如下所示:
func runSTM(s STM, apply func(STM) error) (*v3.TxnResponse, error) {
outc := make(chan stmResponse, 1)
go func() {
defer func() {
if r := recover(); r != nil {
e, ok := r.(stmError)
if !ok {
// client apply panicked
panic(r)
}
outc <- stmResponse{nil, e.err}
}
}()
var out stmResponse
for {
s.reset()
if out.err = apply(s); out.err != nil {
break
}
if out.resp = s.commit(); out.resp != nil {
break
}
}
outc <- out
}()
r := <-outc
return r.resp, r.err
}
runstm 主要是循环执行以下三个步骤:
- 重置 stm,清空 STM 的读写缓存
- 执行事务操作,apply 函数
- 提交事务
etcd client 最终执行提交事务的操作:
txnresp, err := s.client.Txn(s.ctx).If(s.conflicts()...).Then(s.wset.puts()...).Commit()
4、STM 实现细节
下面我们来看 STM 的实现原理。通过上面转账的例子,我们可以看到 STM 的使用特别简单,只需把业务相关的代码封装成可重入的函数传给 stm,而 STM 可自行处理事务相关的细节。
// 位于 clientv3/concurrency/stm.go:25
type STM interface {
// Get 返回键的值,并将该键插入 txn 的 read set 中。如果 Get 失败,它将以错误中止事务,没有返回
Get(key ...string) string
// Put 在 write set 中增加键值对
Put(key, val string, opts ...v3.OpOption)
// Rev 返回 read set 中某个键指定的版本号
Rev(key string) int64
// Del 删除某个键
Del(key string)
// commit 尝试提交事务到 etcd server
commit() *v3.TxnResponse
reset()
}
STM 是软件事务存储的接口。其中定义了 Get、Put、Rev、Del、commit、reset 接口方法。STM 的接口有两个实现类:stm 和 stmSerializable
。具体选择哪一个,**由我们指定的隔离级别决定。
STM 对象在内部构造 txn 事务,业务函数转换成If-Then,自动提交事务以及处理失败重试等工作,直到事务执行成功。核心的NewSTM函数的实现如下所示:
// NewSTM initiates a new STM instance, using serializable snapshot isolation by default.
func NewSTM(c *v3.Client, apply func(STM) error, so ...stmOption) (*v3.TxnResponse, error) {
opts := &stmOptions{ctx: c.Ctx()}
for _, f := range so {
f(opts)
}
if len(opts.prefetch) != 0 {
f := apply
apply = func(s STM) error {
s.Get(opts.prefetch...)
return f(s)
}
}
return runSTM(mkSTM(c, opts), apply)
}
根据源码可以知道,NewSTM
首先判断该事务是否存在预取的键值对,如果存在,会无条件地直接 apply 函数;否则会创建一个 stm,并运行 stm 事务。runSTM 代码如下所示:
// 位于 clientv3/concurrency/stm.go:140
func runSTM(s STM, apply func(STM) error) (*v3.TxnResponse, error) {
outc := make(chan stmResponse, 1)
go func() {
defer func() {
if r := recover(); r != nil {
e, ok := r.(stmError)
if !ok {
// 执行异常
panic(r)
}
outc <- stmResponse{nil, e.err}
}
}()
var out stmResponse
for {
// 重置 stm
s.reset()
// 执行事务操作,apply 函数
if out.err = apply(s); out.err != nil {
break
}
// 提交事务
if out.resp = s.commit(); out.resp != nil {
break
}
}
outc <- out
}()
r := <-outc
return r.resp, r.err
}
runSTM 函数首先重置了 stm,清空 STM 的读写缓存;接着执行事务操作,apply 应用函数;最后将事务提交。提交事务的实现如下:
// 位于 clientv3/concurrency/stm.go:265
func (s *stm) commit() *v3.TxnResponse {
txnresp, err := s.client.Txn(s.ctx).If(s.conflicts()...).Then(s.wset.puts()...).Commit()
if err != nil {
panic(stmError{err})
}
if txnresp.Succeeded {
return txnresp
}
return nil
}
上述 commit 的实现包含了我们前面所介绍的 etcd 事务语法。If 中封装了冲突检测条件,提交事务则是 etcd 的 Txn 将 wset 中的数据写入并提交的过程。
下面我们来看看 etcd 隔离级别以及在 STM 封装基础上如何实现事务。
4、etcd 事务隔离级别
数据库有如下几种事务隔离级别 (Transaction Isolation Levels):
- 未提交读(Read Uncommitted):能够读取到其他事务中还未提交的数据,这可能会导致脏读的问题。
- 读已提交(Read Committed):只能读取到已经提交的数据,即别的事务一提交,当前事务就能读取到被修改的数据,这可能导致不可重复读的问题。
- 可重复读(Repeated Read):一个事务中,同一个读操作在事务的任意时刻都能得到同样的结果,其他事务的提交操作对本事务不会产生影响。
- 串行化(Serializable):串行化的执行可能冲突的事务,即一个事务会阻塞其他事务。它通过牺牲并发能力来换取数据的安全,属于最高的隔离级别。
而 etcd clientv3 实现了四种事务模型,位于 clientv3/concurrency/stm.go 中,分别为 SerializableSnapshot、Serializable、RepeatableReads 和 ReadCommitted。
// 位于 clientv3/concurrency/stm.go:45
const (
// SerializableSnapshot provides serializable isolation and also checks
// for write conflicts.
SerializableSnapshot Isolation = iota
// Serializable reads within the same transaction attempt return data
// from the at the revision of the first read.
Serializable
// RepeatableReads reads within the same transaction attempt always
// return the same data.
RepeatableReads
// ReadCommitted reads keys from any committed revision.
ReadCommitted
)
// WithIsolation specifies the transaction isolation level.
func WithIsolation(lvl Isolation) stmOption {
return func(so *stmOptions) { so.iso = lvl }
}
STM 的事务级别通过 stmOption 指定,默认就是 SerializableSnapshot。下面分别介绍这几种隔离级别。
构造 STM 的实现如下所示:
// 位于 clientv3/concurrency/stm.go:105
func mkSTM(c *v3.Client, opts *stmOptions) STM {
switch opts.iso {
// 串行化快照
case SerializableSnapshot:
s := &stmSerializable{
stm: stm{client: c, ctx: opts.ctx},
prefetch: make(map[string]*v3.GetResponse),
}
s.conflicts = func() []v3.Cmp {
return append(s.rset.cmps(), s.wset.cmps(s.rset.first()+1)...)
}
return s
// 串行化
case Serializable:
s := &stmSerializable{
stm: stm{client: c, ctx: opts.ctx},
prefetch: make(map[string]*v3.GetResponse),
}
s.conflicts = func() []v3.Cmp { return s.rset.cmps() }
return s
// 可重复读
case RepeatableReads:
s := &stm{client: c, ctx: opts.ctx, getOpts: []v3.OpOption{v3.WithSerializable()}}
s.conflicts = func() []v3.Cmp { return s.rset.cmps() }
return s
// 已提交读
case ReadCommitted:
s := &stm{client: c, ctx: opts.ctx, getOpts: []v3.OpOption{v3.WithSerializable()}}
s.conflicts = func() []v3.Cmp { return nil }
return s
default:
panic("unsupported stm")
}
}
该函数是根据隔离级别定义的。每一类隔离级别对应不同的冲突检测条件,存在读操作差异,因此我们需要搞清楚每一类隔离级别在这两方面的实现。
从构建 SMT 的实现代码可以知道,etcd 隔离级别与一般的数据库隔离级别的差异是没有未提交读的隔离级别,这是由于 etcd 的 kv 操作(包括 txn 事务内的多个 keys 操作)都是原子操作,所以你不可能读到未提交的修改。下面我们将从低到高分别介绍 etcd 事务隔离级别。
4.1 ReadCommitted
读提交是指,一个事务提交之后,它做的变更才会被其他事务看到。只允许获取已经提交的数据。比如事务 A 和事务 B 同时进行,事务 A 进行 +1 操作,此时,事务 B 无法看到这个数据项在事务A操作过程中的所有中间值,只能看到最终的 10。
由于 etcd 的 kv 操作(包括 txn 事务内的多个 keys 操作)都是原子操作,所以你不可能读到未提交的修改,ReadCommitted 是 etcd 中的最低事务级别。
由构造 STM 的源码可知,ReadCommitted 调用的是 stm 的实现。对于不一样的隔离级别,我们主要关注的就是读操作和提交时的冲突检测条件。而对于写操作,会先写进本地缓存,直到事务提交时才真正写到 etcd 里。
- 读操作
func (s *stm) Get(keys ...string) string {
if wv := s.wset.get(keys...); wv != nil {
return wv.val
}
return respToValue(s.fetch(keys...))
}
从 etcd 读取 keys,就像普通的 kv 操作一样。第一次 Get 后,在事务中缓存,后续不再从 etcd 读取。
- 冲突检测条件
s.conflicts = func() []v3.Cmp { return nil }
没有任何冲突检测。
ReadCommitted 只需要确保自己读到的是别人已经提交的数据,由于 etcd 的 kv 操作都是原子操作,所以不可能读到未提交的修改。
4.2 RepeatableReads
可重复读是指,一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的。多次读取同一个数据时,其值都和事务开始时刻是一致的,因此该事务级别解决了不可重复读取和脏读取的问题,但是有可能出现幻影数据。所谓幻影数据,在一个事务内多次查询某个符合查询条件的「记录数量」,如果出现前后两次查询到的记录数量不一样的情况,就意味着发生了「幻读」现象。
- 读操作
与 ReadCommitted 类似,用 readSet 缓存已经读过的数据,这样下次再读取相同数据的时候才能得到同样的结果,确保了可重复读。
- 冲突检测条件
s.conflicts = func() []v3.Cmp { return s.rset.cmps() }
在事务提交时,确保事务中 Get 的 keys 没有被改动过。因此使用 readSet 数据的 ModRevision 做冲突检测,确保本事务读到的数据都是最新的。
MySQL 事务“可重复读”是通过在事务第一次 select 时建立 readview,来确保事务中读到的是到这一刻为止的最新数据,忽略后面发生的更新。而这里每个 key 的 Get 是独立的(也可以说,每个 key 都是获取的当前值,没有 readview 的概念),在事务提交时,如果这些 keys 没有变动过,那么事务就可以提交。
4.3 Serializable
串行化,顾名思义是对同一行记录,“写”会加“写锁”,“读”会加“读锁”。当出现读写锁冲突的时候,后访问的事务必须等前一个事务执行完成,才能继续执行。是最严格的事务隔离级别,它要求所有事务被串行执行。
- 读操作
func (s *stmSerializable) Get(keys ...string) string {
if wv := s.wset.get(keys...); wv != nil {
return wv.val
}
// 判断是否第一次读
firstRead := len(s.rset) == 0
for _, key := range keys {
if resp, ok := s.prefetch[key]; ok {
delete(s.prefetch, key)
s.rset[key] = resp
}
}
resp := s.stm.fetch(keys...)
if firstRead {
// 记录下第一次读的版本作为基准
s.getOpts = []v3.OpOption{
v3.WithRev(resp.Header.Revision),
v3.WithSerializable(),
}
}
return respToValue(resp)
}
事务中第一次读操作完成时,保存当前版本号 Revision;后续其他读请求会带上这个版本号,获取指定 Revision 版本的数据。这确保了该事务所有的读操作读到的都是同一时刻的内容。
- 冲突检测条件
s.conflicts = func() []v3.Cmp { return s.rset.cmps() }
在事务提交时,需要检查事务中 Get 的 keys 是否被改动过,而 etcd 串行化的约束还不够,它缺少了验证事务要修改的 keys 这一步。下面的 SerializableSnapshot 事务增加了这个约束。
可见,这个约束比数据库串行化的约束要低,它没有验证事务要修改的 keys 是否被改动过,下面的 SerializableSnapshot 事务增加了这个约束。
4.4 SerializableSnapshot
SerializableSnapshot串行化快照隔离,提供可序列化的隔离,并检查写冲突。etcd 默认采用这种隔离级别,串行化快照隔离是最严格的隔离级别,可以避免幻影读。其读操作与冲突检测的过程如下。
- 读操作
与 Serializable 串行化读类似。事务中的第一个 Get 操作发生时,保存服务器返回的当前 Revision;后续对其他 keys 的 Get 操作,指定获取 Revision 版本的 value。
- 冲突检测条件
s.conflicts = func() []v3.Cmp {
return append(s.rset.cmps(), s.wset.cmps(s.rset.first()+1)...)
}
在事务提交时,检查事务中 Get 的 keys 以及要修改的 keys 是否被改动过。
SerializableSnapshot 不仅确保了读取过的数据是最新的,同时也确保了要写入的数据同样没有被其他事务更改过,是隔离的最高级别。
通过上面的分析,我们清楚了如何使用 etcd 的 txn 事务,构建符合 ACID 语义的事务框架。如果这些语义不能满足你的业务需求,通过扩展 etcd 的官方 client sdk,写一个新 STM 事务类型即可。
需要强调的是,数据库事务是“锁/阻塞”模式,而 etcd 的 STM 事务是 “CAS/重试” 模式,这是有差别的。简单的说,数据库事务不会自己重试,而 STM 事务在发生冲突是会多次重试,必须要保证业务代码是可重试
的,且必须有明确的失败条件(例如判断账户余额是否够转账)。
参考资料:
谈一谈如何使用etcd中的事务的更多相关文章
- 谈一谈Java8的函数式编程(二) --Java8中的流
流与集合 众所周知,日常开发与操作中涉及到集合的操作相当频繁,而java中对于集合的操作又是相当麻烦.这里你可能就有疑问了,我感觉平常开发的时候操作集合时不麻烦呀?那下面我们从一个例子说起. 计 ...
- 【ASP.NET MVC系列】浅谈jqGrid 在ASP.NET MVC中增删改查
ASP.NET MVC系列文章 [01]浅谈Google Chrome浏览器(理论篇) [02]浅谈Google Chrome浏览器(操作篇)(上) [03]浅谈Google Chrome浏览器(操作 ...
- 浅谈SQL Server中的事务日志(一)----事务日志的物理和逻辑构架
简介 SQL Server中的事务日志无疑是SQL Server中最重要的部分之一.因为SQL SERVER利用事务日志来确保持久性(Durability)和事务回滚(Rollback).从而还部分确 ...
- 浅谈mysql中不同事务隔离级别下数据的显示效果
事务的概念 事 务是一组原子性的SQL查询语句,也可以被看做一个工作单元.如果数据库引擎能够成功地对数据库应用所有的查询语句,它就会执行所有查询,如果任何一条查 询语句因为崩溃或其他原因而无法执行,那 ...
- SQL Server误区30日谈 第26天 SQL Server中存在真正的“事务嵌套”
误区 #26: SQL Server中存在真正的“事务嵌套”错误 嵌套事务可不会像其语法表现的那样看起来允许事务嵌套.我真不知道为什么有人会这样写代码,我唯一能够想到的就是某个哥们对SQL Serve ...
- 浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色
简介 生产环境下的数据是如果可以写在资产负债表上的话,我想这个资产所占的数额一定不会小.而墨菲定律(事情如果有变坏的可能,无论这种可能性有多小,它总会发生)仿佛是给DBA量身定做的.在上篇文章介绍的简 ...
- 谈一谈泛型(Generic)
谈一谈泛型 首先,泛型是C#2出现的.这也是C#2一个重要的新特性.泛型的好处之一就是在编译时执行更多的检查. 泛型类型和类型参数 泛型的两种形式:泛型类型( 包括类.接口.委托和结构 没有泛型枚 ...
- 从一张图开始,谈一谈.NET Core和前后端技术的演进之路
从一张图开始,谈一谈.NET Core和前后端技术的演进之路 邹溪源,李文强,来自长沙.NET技术社区 一张图 2019年3月10日,在长沙.NET 技术社区组织的技术沙龙<.NET Core和 ...
- 谈一谈Elasticsearch的集群部署
Elasticsearch天生就支持分布式部署,通过集群部署可以提高系统的可用性.本文重点谈一谈Elasticsearch的集群节点相关问题,搞清楚这些是进行Elasticsearch集群部署和拓 ...
- 谈一谈iOS事件的产生和传递
谈一谈iOS事件的产生和传递 1.事件的产生 发生触摸事件后,系统会将该事件加入到一个由UIApplication管理的事件队列中. UIApplication会从事件队列中取出最前面的事件,并将事件 ...
随机推荐
- Windows 远程时提示CredSSP 加密数据库修正 问题的简单处理.
最近在公司内部远程机器的时候更新了 windows上面远程部分服务器的时候出现异常如图示: 查了下 还是有比较简单的解决办法的 问题是需要在 自己的客户端机器上面进行设置 不需要修改服务器端的服务器. ...
- 你也能成为“黑客”高手——趣谈Linux Shell编程语言
作者:京东零售 杜兴文 我们看过很多在电脑命令行敲一些命令并给观众展示很高科技的画面感的电影,比如<盗梦空间><操作系统革命><代码>等等, 再想想电影黑客帝国中的 ...
- 【图论】CF1508C Complete the MST
Problem Link 有一张 \(n\) 个点的完全图,其中 \(m\) 条边已经标有边权.你需要给剩下的边都标上权值,使得所有边权的异或和为 \(0\),并且整张图的最小生成树边权和最小. \( ...
- 学习MySQL中DDL语句的修改字段与删除字段,删除表
连接本地mysql语句 mysql -hlocalhost -uroot -proot 显示表结构 语法:desc 表名 查看某一个表结构以及注释 语法:show create table 表名 sh ...
- elementUI自定义单选框内容
<template> <div> <div class="heng-div"> <el-radio v-model="radio ...
- 每日一库:cobra 简介
当你需要为你的 Go 项目创建一个强大的命令行工具时,你可能会遇到许多挑战,比如如何定义命令.标志和参数,如何生成详细的帮助文档,如何支持子命令等等.为了解决这些问题,github.com/spf13 ...
- 从零开始配置vim(19)——终端配置
在上一篇文章中,我们熟悉了终端模式,并且配置了终端模式的一些操作.但是它总是有那么一点不符合我们的使用习惯.这篇我们将通过强大的插件来完善终端操作的体验. 在介绍插件之前让我们先回退到上一个版本,我们 ...
- 6.5 Windows驱动开发:内核枚举PspCidTable句柄表
在 Windows 操作系统内核中,PspCidTable 通常是与进程(Process)管理相关的数据结构之一.它与进程的标识和管理有关,每个进程都有一个唯一的标识符,称为进程 ID(PID).与之 ...
- Flask Echarts 实现历史图形查询
Flask前后端数据动态交互涉及用户界面与服务器之间的灵活数据传递.用户界面使用ECharts图形库实时渲染数据.它提供了丰富多彩.交互性强的图表和地图,能够在网页上直观.生动地展示数据.EChart ...
- 4.1 C++ Boost 字符串处理库
Boost 库是一个由C/C++语言的开发者创建并更新维护的开源类库,其提供了许多功能强大的程序库和工具,用于开发高质量.可移植.高效的C应用程序.Boost库可以作为标准C库的后备,通常被称为准标准 ...