Algorithm

139. 单词拆分

func wordBreak(s string, wordDict []string) bool {
    wordDictMap := make(map[string]bool)
    for _, v := range wordDict {
        wordDictMap[v] = true
    }
    results := make([]bool, len(s)+1)
    results[0] = true
    for i := 1; i <= len(s); i++ {
        results[i] = false
        for j := 0; j < i; j++ {
            _, ok := wordDictMap[s[j:i]]
            if results[j] && ok {
                results[i] = true
                break
            }
        }
    }
    return results[len(s)]
}

Review

Write a Web Service with Go Plug-Ins
文章介绍了go-plugin的入门使用方法，可用于即插即用的功能。

TIP

最近在项目开发中遇到一个需求：

1. 前端页面有多行操作记录，这些记录有先后顺序的概念
2. 可以对这些操作记录进行增删改查功能。
3. 对这些操作记录，还需要支持拖拽改变先后顺序的操作。

增删改查都还好说，数据库中对对应的row进行create、delete、update就可以了，难点在于如何实现“记录有先后顺序”这个需求。假设原来有2行操作记录：

现在如果要将记录2拖动到记录1的前面，代码和sql要如何编写呢？经过查阅资料，想到一个链表的结局方案。
简单来说就是在数据库中增加一个next_record_id字段，用来标识这个节点指向的下一个节点，然后再在代码中通过拼接链表的方式将所有record进行排序再输出给前端。修改后的数据库设计如下：

这里需要注意的是我们需要用-1来代表这一行数据为尾节点。
引入了next_record_id字段之后，对增删改都增加了一定并发复杂度，原来增加一个节点只需要写一个create sql就好了，但是现在需要如下操作：

1. 前端调用后端add接口，传入需要增加的信息，同时需要告诉后端pre_record_id，也就是目前前端上认为的尾节点。
2. 通过for update将原本的尾巴节点节点1锁住，避免其他并发操作修改节点1。同时对节点1加锁的for update语句需要在where 条件中加上 next_record_id=-1的乐观锁来避免节点1已经被其他用户update过了。完整sql应该是：select ID from xxx where next_record_id=-1 for update.
3. 执行create sql增加一个新的尾巴节点节点2。
4. update原本的尾部节点1的next_record_id字段指向新增的节点2。
5. 需要特别注意的是以上所有操作需要在一个数据库事务里面。

其他的删改拖拽操作也是一样的：老节点加锁、对需要更新的节点进行更新、修改相关record的next_record_id。

Share

学习mysql 45讲

29 | 如何判断一个数据库是不是出问题了？

select 1判断

定期执行select 1并关注是否成功返回。本方法只能说明这个库的进程还在， 并不能说明主库没问题。

查表判断

在系统库（mysql库） 里创建一个表， 比如命名为health_check， 里面只放一行数据， 然后定期执行，通过更新语句是否能够成功来判断数据库是否有问题。
更新事务要写binlog， 而一旦binlog所在磁盘的空间占用率达到100%， 那么所有的更新语句和事务提交的commit语句就都会被堵住。 但是， 系统这时候还是可以正常读数据的。因此这个方案发现不了磁盘堵塞问题。

更新判断

常见做法是放一个timestamp字段， 用来表示最后一次执行检测的时间。 这条更新语句类似于：update mysql.health_check set t_modified=now(); 通过判断更新语句是否成功来判断数据库是否存在问题。
这个方案如果存在双M架构的话，主库A和备库B都用相同的更新命令， 就可能出现行冲突， 也就是可能会导致主备同步停止。为了让主备之间的更新不产生冲突， 我们可以在mysql.health_check表上存入多行数据， 并用A、 B的server_id做主键。

内部统计

MySQL 5.6版本以后提供的performance_schema库， 就在file_summary_by_event_name表里统计了每次IO请求的时间。我们可以通过打开对应的检测开关来记录IO请求时间，从而及时发现暴露问题。