真直男程序员思维，好尴尬的东西...你还不如打印出来做成书。

可以试试 heidisql ，我觉得挺好用的

喜欢小模型的，可以买那种恐龙模型（一个蛋，里面有十多个小恐龙模型），同理还有兵人模型。

我觉得让座、帮别人推车这种无关”利益”的可以帮，但是隔壁那种情况还是别自己上手了。

你同事惨了，给的这 1000 就是自认是他干的。后续老人再闹要钱怎么办。
这种情况首先不要管！不是你撞的为什么要扶？
就算扶了，三不一没有！不垫付医药费、不去医院探望伤者、不接受调解，以及不出一分钱。

我猜的，看样子是报错了，前端直接打日志骂人，结果忘了删除。没有 CR 的吗，哈哈哈哈

对 python 一点影响都没有

快进到谷歌解雇全部 golang 团队

同样推荐 geektutu 的 7 天系列，另外那个一直推自己 kv 课程的马甲也太多了...

参考草台班子论

他这个数据库是自己从 0 开始写的吗？还是开源套皮的

敢用提权漏洞来获取用户信息，还有什么不敢干的。最恶心的公司

@marc2017 还有 acceed ，最近看了很多 inm 视频，哈哈哈

我来斗胆回答一下，麻烦各位大佬指正：

抢课是谁先到先得模式，还是先报名再摇号方式？考虑到学校的硬件性能不会太好，先开启限流，比如 nginx ，就让 1 秒钟只有 500 个请求，避免系统崩溃。抢课过程：
第一种，可以开启事务，开启事务->扣减课程余额->给学生添加课程信息->结束事务；
第二种，先在内存中记录下课程 id 和对应的学生学号。比如限制一天内报名，到期后，随机抽取 n 个学生。然后余额=0 ，给学生添加课程信息。可以使用 redis ，或者本地 cache

redis 满了，看是不是某些超大的 key 没有设置过期时间，可以优先把这种忘记设置过期时间的临时 key 删除掉。如果 key 都在使用中，而且数据都有意义，只能加内存。开启内存淘汰机制，LRU

解决高并发的本质是什么？
资源是有限制的，对于远超资源的流量，如何处理。比如抢课，只有 50 个名额，但是有 500 个学生要来抢课；或者说我的服务器硬件不行，无法处理那么多请求，大量流量下如何不宕机。首先要限流，不让系统被大流量打崩溃。到了具体的数据要加锁处理。数据修改完了，后续的其他操作（比如给学生添加课程信息），异步解耦还是跟着同步操作。