本周主要做了两件事：两个关于消息队列的脚本，修改了之前脚本上的以及业务逻辑中的一些bug, 把禁言部分的逻辑抽到了user表中。
在封装rabbitmq的时候，又看了官方文档，但是每次都看的不是很细，总是在找例子看。增加put的时候断开连接的逻辑时，出了不少bug, 而封装get方法的时候，完全不知道怎么去写，写出来的和预期的相差很远。pika里面，提供了channel.consume 和 channel.basic_get. 当时看着consume的例子，觉得这个符合我批量操作的业务需求，就开始改了，后来发现它是阻塞的，阻塞的，队列取完了，就会卡住，而我不知道什么时候会取完， 着急的时候开始更深入的去看consume的这个函数，发现里面有一个参数 inactivity_timeout, 如果设置为2，队列取不到数据会返回None. 貌似是解决了这个问题。但是实际情况是，每秒钟都会有好几次请求，队列根本不会为空。 放弃这种情况之后，开始深入去看basic_get方法，才发现它是非阻塞的，有数据就返回，没数据就返回None. 很容易使用。 而这完全是没有仔细看官方文档导致的！！！
我现在解决问题，也是手里拿着锤子，看哪都是钉子。没有根据具体的业务场景去考虑，我这里是用listen比较好，还是get比较好。没有深入代码去思考，我的代码还能不能更近一步。今天又被老大提醒要多思考，50%的时间去想，50%的时间写代码。没有深入去看代码，看到一点做一点，这很容易会出现问题。 这是我的一个bug,得赶快改。
这周还改了之前一个活动里面的事务的代码，用了老大封装的事务模块，这个模块主要就是负责建立连接， 实现了enter和exit的方法。 修复的一个bug是decimal在数据库中定义的，返回的也是decimal.这种情况下，需要用float或者int转一下，否则会无法识别。
禁言里面的逻辑主要就是一个搬迁，关于禁言部分，我印象深刻的是批量update. 这里有一个方法 update table_name set columns= case id when 1 then 2 when 2 then 3 end where id in (1,2); 这个批量操作在固态硬盘下还是很快的。每次1000条还是可以的。
在修改之前业务代码的时候又体验了一把拼接sql语句的痛苦。。。当时我在网上搜，搜了个re.escape就给用了。实际上呢？这个是把正则相关的都给转义了。 在python编译器里面，print 出来的是实际的字符串，没有print的是转义的，而转义是要在没有print的基础上再操作的。
这周最先做的东西给忘了。。。 之前使用项目中七牛保存图片是下载到本地，然后上传服务器的，而实际上官网提供了一种方法，就是七牛可以自己去抓，返回的url,后面加一个imageInfo,就可以拿到这个图片的相关数据，如果不是图片，会返回异常。
这周还抽了20分钟爬了个小说，因为没有反爬，所有很容易就爬下来了。
反思：
1.以后要多抽时间去读一读官方文档。读官方文档，一定要把接口给过一下！！！
2.花更多的时间去想，而不是上手去写！！！
3.优化代码的时候，要把之前代码要做的给缕清楚，不是看到一点就上手去改，容易改漏和出问题！！！
4.以后起每天都要做好今日的总结和记录，每日反思！！！