文章列表

1.6k 字 1 分钟

如今结合文档已经比较清楚了，在这里记录一下几个特殊的使用。 # 服务端 服务端的配置比较简单，主要就是配置一下监听的端口和 token 之类的： bindPort = 7000auth.token = "xxxxx"# 客户端 # 普通服务 一开始想配置 http 服务，看到示例设置了域名，但没有设置端口。按照网上一些教程加上 remotePort 还报错了。实际上如下的配置是需要通过域名来区分不同的服务的，type="http" 的时候，没有 remotePort 这个选项： serverAddr =...
1.2k 字 1 分钟

质数是除了 1 和它本身，没有其他因数的自然数，根据其定义，很容易想到对于数字 N (N >= 2) 通过遍历，判断 2 ~ N - 1 之间的数能否整除 N ，能则不是，否则是： func isPrime(n int) bool { if n < 2 { return false } for i := 2; i < n; i++ { if n%i == 0 { return false } } return...
1.4k 字 1 分钟

为何需要分布式锁？在单机的服务中，对于并发下的锁争用，可以在进程内实现。然而分布式的情况下，各个服务分开部署，无法通过这种方式获得，因此需要分布式锁来进行同步。 # 实现 分布式锁可以怎样实现呢？实际上主要就是能够实现一个大家都能读写的东西，且保证一个写入了另一个能感知到并被拒绝，也就实现了所谓的锁。 # MySQL 依靠 MySQL 的唯一性去保证，例如插入一条记录，根据主键 / 唯一性的列，来保证只有一个能插入成功，成功者即获得锁。 同时需要设置好记录的时间，以便于实现超时释放的问题，避免死锁。 但高并发的情况下，MySQL 死锁检测比较影响效率，相对来说它是比较重的，较少用于加锁。 #...
4k 字 4 分钟

MySQL 的一些动作的执行流程记录。 # 更新 执行： update T set c=c+1 where ID=2; 其中浅色由 InnoDB 引擎执行，深色由 server 层执行器执行。先写入 redo log，标记为 prepare；再写入 binlog；再提交事物，标记 redo log 为 commit，此为两阶段提交。 为什么需要？ 确保数据正确性。binlog 属于 Server 层的日志，而 InnoDB 层为实现 crash-safe ，实现了 redo log 日志。它们有以下不同： redo log 是物理日志，记录了数据页做的修改；binlog...
1.9k 字 2 分钟

当引入缓存后，不可避免的会出现缓存一致性的问题。当数据进行了更新操作，如何保证缓存中的数据能够得到正确的更新？下面就来讨论一下这个问题。 # 更新的模式 考虑不同的方式，要同时考虑两步中一个成功另一个失败的情况，同时要考虑并发操作的情况。 先缓存后数据库 这种方式明显不行，数据库是最终持久化数据的地方，只有再确保数据更新完成后才去更新缓存，避免数据保存失败的问题。 更新数据库再更新缓存 确保的数据已经更新成功，但在并发情况下，无法保证其顺序。例如 A 更新 X=1，B 更新 X=2，但可能 B 先去写了缓存，而 A 后去又覆盖了缓存，导致缓存变成过期数据。在 1...
2.6k 字 2 分钟

Redis 提供的持久化，可以避免进程退出造成的数据丢失的问题。启动时，通过加载持久化文件，可以恢复之前的数据。Redis 提供了两种持久化的方式： # RDB RDB 持久化是把当前进程数据生成快照保存到硬盘的过程。 触发方式有主动触发和手动触发。 # 触发机制 手动触发命令： save 阻塞当前 redis 服务器，直到 RDB 完成 bgsave fork 子进程进行 RDB 操作，阻塞只存在于 fork 期间 除了手动触发，redis 内部还存在自动触发的机制，例如以下场景： 使用 save 配置，如： save m n ，表示 m 秒内数据集存在 n 次修改时自动...
3.4k 字 3 分钟

应对大流量，通常不会单独的在某一层进行分流处理，可能很多层面都有相应的分流处理，以更好的适应大流量的访问。 # 客户端缓存 对于一些不常更改的资源，缓存到客户端本地，可以有效减少对服务器的访问。在 http 请求中，有以下这些常见的缓存方式： Expires 从 HTTP/1.0 开始提供的 Header，后面跟上过期时间。但受限于本地的时间正确性，可能导致缓存提前失效或超期持有，也无法描述‘不缓存’语义。 Cache-Control HTTP/1.1 定义的 Header，与 Expires 冲突则以此为准，常见有 max-age=100...
2.1k 字 2 分钟

使用上传的时候，总是遇到各种问题，每次搜索之后用上便忘记，这里总结一下几种上传的方式和遇到的问题。 # 数据的绑定问题 上传组件有属性 file-list ， 但并没有双向绑定，主要还是用于显示已上传的文件使用的。传入对象数组，每个对象需要有 url 属性，某些样式的上传框还有 name 需要显示。 [ { url: '', name: '' }]上传之后这个数组并不会更新，因此需要自己维护上传的文件列表，尤其是已经上传的，和本次上传的。 由于各种事件，各种状态，更新维护数组容易混乱，最好还是在最后上传删除都完成后，通过...