Django REST framework小探

偶然发现
1. 不带CSRF信息
2. 没有session相关的cookie
也能正常访问API

调试发现,接口的访问通过REST framework的ApiView,而这个View的authentication_classes和permission_classes, throttle_classes都是使用的默认的
在默认情况下,authentication_classes的值是:

'DEFAULT_AUTHENTICATION_CLASSES': (
    'rest_framework.authentication.SessionAuthentication',
    'rest_framework.authentication.BasicAuthentication'
)

permission_classes的值是:

'DEFAULT_PERMISSION_CLASSES': (
    'rest_framework.permissions.AllowAny',
)

throttle_classes的值是:

'DEFAULT_THROTTLE_CLASSES': (),

而根据Django REST framework的设定相关代码):

Authentication is the mechanism of associating an incoming request with a set of identifying credentials, such as the user the request came from, or the token that it was signed with. The permission and throttling policies can then use those credentials to determine if the request should be permitted.

authentication本身并不决定请求是否应该被拒绝,所以在没有用户登录的情况下(没有session相关cookie),请求仍能到达业务处理函数

另一个问题是,CSRF为何没有发挥作用,原因是:
根据这里

# Note: session based authentication is explicitly CSRF validated,
# all other authentication is CSRF exempt.

只有SessionAuthentication才会做CSRF检查,而根据SessionAuthentication的代码,检测到没有活跃用户,就不再做CSRF防御了

高晓松的脱口秀

从,奇葩说,看到晓松奇谈,晓说,晓松说,晓说2017
一路走来,对高晓松有了不少自己的看法
家境优越,早年成名,因醉驾做过半年牢
看脱口秀,能感受到他知识范围很广,其中,讲的最多的领域应该是历史,文学,音乐,电影
能感觉到他经历丰富,圈子广,情商高,的确也很有才华
能平淡的对待世界,有自己的看法与处事方式,而不偏激,不虚荣,不自大。
对于我而言,很喜欢他讲述的方式和态度,客观事实(虽然很多待考证或者难以考证)偏多,加上不偏激的解说
从最开始的完全顶礼膜拜,后来也慢慢趋于平和
慢慢的有了一些疑问(譬如对林语堂的前后的观点的变化,金瓶梅中的一夫多妾与经常提到的一夫一妻一妾多婢多姬),和发现了不少重复,面向大众(可能有时候会受政治影响,着重讲一些东西),性格过于开朗能说(而可能有时候会缺少一些准确),也大概是有些审美疲劳

中关村创业大街

参加百度开发者沙龙,发现自己是第一次去中关村创业大街
这种规模的,免费的沙龙是第一次去
4个讲师,2个技术,一个运营,一个产品
半场离场,一个原因是座位不好,有些压抑。更主要的原因是感觉演讲的内容并不是自己真正需要的。
进而想到这样的沙龙,听众繁杂,每人的知识基础和诉求也不一样,也很难完全符合某一个人的口味
随着年龄的增长,慢慢认识到除技术之外的东西的重要性,产品,推广,运营
也慢慢对技术有了一个更加全面的认识,大部分的技术应该以产品为主,产品和技术协调共同达成公司(部门)的目标
对于技术本身而言,大部分是,比较重要的是整体的架构,各个服务的调用关系,各个组件通信的方式,各个组件存在的目的。在整体架构正确的情况下,然后是单个项目(服务)的结构,代码的组织方式,主要的执行流程。之后可能才是具体的代码,包含某一个功能的具体实现方式,某些函数的设计,如何把代码写的简单可读而稳定,代码风格等。当然,根据不同场景,某些核心功能的核心模块的算法设计和实现也很重要。
越来越多的思考,一个公司的成功,一个产品的成功,社会及世界的运行方式,人们协作的方式。与此同时,也更加清楚的认识了自己的特点,局限性,擅长的地方与很笨拙的地方。

使用redis的Sorted Set解决“助我夺宝”

助我夺宝需求描述如下:
1.用户可以助威好友
2.用户按照助威数和最后一个助威的时间排名
3.排名特定区间的用户可以获得奖品,如排名1-3获得奖品一,排名4-8可以获得奖品二,等等
4.实时获取用户当前排名,以及距离下一区间奖品需要的助威数

问题的难点在于用户的排名是不断变化中的,利用redis的Sorted Set却可以比较好的完成这项需求

首先可以用关系型数据库mysql存储
prize表 — 奖品信息
user表 — 用户信息
access_record表 — 用户助威好友的记录

然后设置Sorted Set的
member — 用户ID
score — 助威数*1e10 + (1e10 – 助威记录ID) # 这里假设助威记录ID小于1e10(根据redis文档,score的取值范围是-2^53与2^53之间),助威记录ID按照时间递增

然后就可以提供以下功能:
助威 — 先使用zscore取出旧的score,然后可以算出之前的助威数,将助威数加1,再用zadd将新的score存入redis
计算用户排名 — 使用zrevrank
获取排名前num的用户 — 使用zrevrange
计算某一用户距离下一区间奖品需要的助威数 — 先取出此用户对应rank和score,根据rank计算下一排名区间的最低rank(如4-8名获得奖品二,8-15名获得奖品三,用户当前rank为10,则下一区间奖品最低rank为8),使用zrevrange得到最低rank对应的score_min,根据score_min和score分别计算得到助威数help_num_min和help_num,则help_num_min+1-help_num即是需要的助威数

假设参与排名的用户数为n个,以上用到的redis操作中,zadd, zrevrank的时间复杂度为O(log(n)),zrevrang根据取出的元素的个数m时间复杂度为O(log(n)+m),zscore的时间复杂度为O(1)

MySQL学习

首先推荐三篇文章:
1.MySQL索引背后的数据结构及算法原理
总体概括了MySQL内部的索引原理及索引使用策略
2.剖析Mysql的InnoDB索引
侧重剖析了InnoDB的Page结构,更加详细的见Jeremy Cole的博客
3.Judy的B树
侧重数据结构的分析,注意只是数据结构。。
此外还有官方的InnoDB文档

总结重要的内容如下:
1. 使用B+的原因,相对于红黑树等二叉查找树,树的高度低,能减少IO次数。相对于B-树,稳定,更利于范围查询。相对于Hash表,更利于范围查询,伸缩性更好(在无法预知表中记录数时),详细见这里的讨论
2. InnoDB与MyISAM索引实现的区别,聚集索引和非聚集索引的区别
3. 建索引时的最左前缀原理,数据库表的主键选择
4. 慢查询日志及explain关键字