总结：：

1. 死锁的背景：作者在一个 Rails 项目中部署了新功能后，发现数据库的一个从库 CPU 使用率接近 100%，API 响应时间变长，并出现了 Statement Timeout 错误。版本回滚后，问题得到解决。

2. 死锁的原因：经过分析，发现死锁是由于一个 Rails migration 触发的，这个 migration 包含了对cars表添加repaired_at列和删除owner_id外键约束的操作。这个操作在从库上导致了死锁。

3. 死锁的模式：死锁发生时，有联表查询语句在等待cars表的AccessShareLock，而另一个进程在等待users表的AccessExclusiveLock。这两个锁是互斥的，导致了死锁。

4. 锁的类型：

   • AccessShareLock：在 SELECT 查询表时使用，仅与AccessExclusiveLock互斥。
   • AccessExclusiveLock：与其他所有锁模式互斥，用于 DDL 操作，如DROP TABLE、TRUNCATE等。

5. DDL 操作的影响：在执行删除外键约束的 DDL 操作时，PostgreSQL 会对被引用的表（在这个案例中是users表）加上AccessExclusiveLock锁，这可能导致与其他查询操作的锁冲突。

6. 问题的具体代码：问题是由以下 Rails migration 代码引起的：

   class AddReparedAtToAndRemoveFkConstraintFromCars < ActiveRecord::Migration[8.0]
    def change
      add_column :cars, :repaired_at, :datetime
      remove_foreign_key :cars, :owner_id
    end
   end
   

   这段代码中的remove_foreign_key操作导致了对users表的锁，从而引发了死锁。

7. 其他思考：

   • 区分症结和现象：确认问题本身是什么，避免将问题的结果误认为是原因。
   • 主库为何没有死锁：主库查询请求少，降低了死锁概率。
   • 另一个从库为何没有问题：另一个从库虽然也遇到了死锁，但最终成功提交了事务。
   • 请求为何不是全部失败：PostgreSQL 的死锁检测机制会在 1 秒后回滚导致死锁的事务，所以大多数请求只是延迟，而不是失败。

如果你的业务数据量非常大的时候 要谨慎使用 join 你可以认为这是一个地雷，不是不能用 要慎用 a.joins(:b).where(c: ['1', '2']) 所有的数据都会做关联 这时候可以改为： ids = a.where(c: ['1', '2']) b.where(a_id: ids )

Good idea 学到了

公司人多，切换系统很复杂，执行也费劲 主要是成本上，我的 要远远大于 阿里的

添加信任，或者卸载 360 不清楚加一个代码 签名好不好用

主要是现在沟通交流用的是 企微、钉钉、飞书，这种的没办法感觉超越

总结的很全面，索引确实是不能乱加的，之前做商城的时候，有过很大的并发，当时前辈用 redis 去处理的，方式不是很好，后面离职了也知道后面改没改

我最近部署了 4 个服务器，从 一个 center os，3 个 ubuntu，部署到崩溃，居然每个报错都不一样 哈哈哈

哈哈 是的 原因是没权限，一直在重试

找了大佬求助了一下。注视掉

现在做的咋样了，头疼的问题多吗？

以前也是一样的，看你遇到的问题，以前不知道都是问大佬，比如 Ruby ON Rails Plus 公园的群，里面好多大佬 现在越到的问题几乎都见到过，经验多了就不用问了

在深圳，太远了，可惜了了 为大西安点赞

看我破你的甲，嘿哈

前段时间用 ruby 做了一个 庭审模拟，类似于法庭那种，核心用的还是 python + AgentScope 可以体验一下：http://jt-smart.com/

ruby 我觉得可以基于复杂应用开发

欢迎入坑

已解决 参考文章：https://coderwall.com/p/nvva7a/setup-oracle-instant-client-and-ruby-oci8-gem-on-mac

主要是需要连接其他系统，难受的一批，打算用 docker 去做，坑可能会少一点吧

推荐 ubuntu 之前 windows WSL2 都用过 不是很舒服

gem 'jwt'

你给他俩嘴巴子，让他写

除了学历，其他都满足++++ 可惜了了

是的，我这个比较偏一些企业的生产部门，做文件管理，如果您有更好的建议，也可以提出来哦

和你说一下我之前的做法，拿到 openid 后

payload = {session_key: result_json["session_key"], openid: result_json["openid"]} # 获取到的信息
payload = {user_id: 1, token_time: 12345678}.merge(payload)
# 使用小程序密钥加密一下
token = JWT.encode payload, applet_secret, 'HS256'

将 最终的 token 返回给前端，你直接存在 session 不行，需要用 token 做解密后判断能不能登录

没毛病

首先非常感谢您的建议

1. 上传需要审核是针对企业内部 有些文件 是需要主管等审核的情况，这个功能可以动态配置的，也可以不用审核，由创建人配置
2. 这个目录和图标是可以切换的（右上角的小图标），至于你说的多级目录也是方便企业做管理（企业生产部做管理会很有用的）
3. 我认为针对标签设置是个不错的建议，我认为可以用颜色做区分，类似于 MACBook 的标签（红色、橙色、蓝色、个人、工作、重要）这些
4. 批量上传功能是有的，批量下载没有做，这个我会做一下，拖动上传也是一个不错的建议，我也会做一下
5. 针对于您的第 6 项，我有做（权限集成、分配）、内、外部共享（自定义权限）、在线浏览（支持 30+ 种文件）
6. 您说的 文件与某些事项、工作、特定日期相互关联的提醒功能。我觉得没必要，单纯的文件管理，不需要关联一些其他工作，如果有可以做外放接口，让其他系统去设定请求，或者您有一些需求案例 提供一下 最好了

这种的可以接受，主要是前端想控制，不让后端去解密后存储

好的

好的 受教了

也许吧。不纠结业务的事 我是觉得前端明文传，后端加密，没什么大问题