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
最近在项目开发中遇到一个需求：
- 前端页面有多行操作记录，这些记录有先后顺序的概念
- 可以对这些操作记录进行增删改查功能。
- 对这些操作记录，还需要支持拖拽改变先后顺序的操作。
增删改查都还好说，数据库中对对应的row进行create、delete、update就可以了，难点在于如何实现“记录有先后顺序”这个需求。假设原来有2行操作记录：
| 主键ID | 记录内容 | 是否删除 |
|---|---|---|
| 1 | 内容1 | false |
| 2 | 内容2 | false |
现在如果要将记录2拖动到记录1的前面，代码和sql要如何编写呢？经过查阅资料，想到一个链表的结局方案。
简单来说就是在数据库中增加一个next_record_id字段，用来标识这个节点指向的下一个节点，然后再在代码中通过拼接链表的方式将所有record进行排序再输出给前端。修改后的数据库设计如下：
| 主键ID | 记录内容 | 是否删除 | next_record_id |
|---|---|---|---|
| 1 | 内容1 | false | 2 |
| 2 | 内容2 | false | -1 |
这里需要注意的是我们需要用-1来代表这一行数据为尾节点。
引入了next_record_id字段之后，对增删改都增加了一定并发复杂度，原来增加一个节点只需要写一个create sql就好了，但是现在需要如下操作：
- 前端调用后端add接口，传入需要增加的信息，同时需要告诉后端pre_record_id，也就是目前前端上认为的尾节点。
- 通过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.
- 执行create sql增加一个新的尾巴节点节点2。
- update原本的尾部节点1的next_record_id字段指向新增的节点2。
- 需要特别注意的是以上所有操作需要在一个数据库事务里面。
其他的删改拖拽操作也是一样的：老节点加锁、对需要更新的节点进行更新、修改相关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请求时间，从而及时发现暴露问题。
