|
16 | 16 |
|
17 | 17 | - 用户(登录(第三方登录)、注册、注销、自服务(个人信息、浏览历史、收货地址、……))
|
18 | 18 |
|
19 |
| - - 商品(分类、列表、详情、搜索、热门搜索、搜索历史、添加到购物车、收藏、关注、……) |
| 19 | + - 商品(分类、列表、详情、搜索、热门搜索、搜索历史、添加到购物车、收藏、关注、评论、……) |
20 | 20 | - 购物车(查看、编辑(修改数量、删除商品、清空))
|
21 | 21 | - 订单(提交订单(支付)、历史订单、订单详情、订单评价、……)
|
22 | 22 | 2. 管理端
|
23 | 23 | - 核心业务实体的CRUD
|
24 |
| - - 定时任务(周期性和触发式) |
25 |
| - - 报表功能(Excel、PDF、ECharts) |
26 |
| - - 权限控制(RBAC) |
27 |
| - - 业务流转(Activity、Airflow、Spiff、自定义) |
28 |
| - - 三方服务(地图、短信、物流、支付、实名认证、天气、监控、……) |
29 |
| - |
30 |
| -> **提示**:可以通过思维导图来进行需求的整理,思维导图上的每个叶子节点都是不可再拆分的功能,而且都是动词。 |
| 24 | + - 定时任务(周期性和非周期性,如处理未支付订单、采集数据对异常事件报警、……) |
| 25 | + - 报表功能(导入导出Excel、PDF等以及前端ECharts统计图表展示) |
| 26 | + - 权限控制(RBAC、白名单、黑名单、……) |
| 27 | + - 业务流转(如发起退款流程,常用流程引擎有:Activity、Airflow、Spiff等) |
| 28 | + - 三方服务(接入地图、短信、物流、支付、实名认证、天气、监控、云存储、……) |
31 | 29 |
|
32 | 30 | ### 物理模型设计
|
33 | 31 |
|
34 |
| -两个概念:SPU(Standard Product Unit)和SKU(Stock Keeping Unit)。 |
| 32 | +首先要搞清楚两个概念:SPU(Standard Product Unit)和SKU(Stock Keeping Unit)。 |
35 | 33 |
|
36 | 34 | - SPU:iPhone 6s
|
37 | 35 | - SKU:iPhone 6s 64G 土豪金
|
|
40 | 38 |
|
41 | 39 | ### 第三方登录
|
42 | 40 |
|
43 |
| -第三方登录是指利用第三方网站(通常是知名社交网站)的账号进行登录验证,比如国内的 QQ、微博,国外的Google、Facebook等,第三方登录大部分都是使用[OAuth](),它是一个关于授权的开放网络标准,得到了广泛的应用,目前通常使用的是2.0版本。关于OAuth的基础知识,可以阅读阮一峰老师的[《理解OAuth 2.0》](http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html)。 |
| 41 | +第三方登录是指利用第三方网站(通常是知名社交网站)的账号进行登录验证(主要是通过知名第三方网站获取到用户相关信息),比如国内的 QQ、微博,国外的Google、Facebook等。第三方登录大部分都是使用[OAuth](<https://en.wikipedia.org/wiki/OAuth>)协议,它是一个关于授权的开放网络标准(**数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌,用来代替密码,供第三方应用使用**),得到了广泛的应用,目前通常使用的是2.0版本。关于OAuth的基础知识,可以阅读阮一峰老师的[《理解OAuth 2.0》](http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html)。关于**令牌**和**密码**的区别,我们可以简单总结出以下三点差异: |
| 42 | + |
| 43 | +1. 令牌是短期的,到期会自动失效,用户自己无法修改。密码一般长期有效,用户不修改,就不会发生变化。 |
| 44 | +2. 令牌可以被数据所有者撤销,会立即失效。以上例而言,屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。 |
| 45 | +3. 令牌有权限范围(scope),比如只能进小区的二号门。对于网络服务来说,只读令牌就比读写令牌更安全。密码一般是完整权限。 |
| 46 | + |
| 47 | +所以,通过令牌既可以让第三方应用获得权限,同时又随时可控,不会危及系统安全。这就是OAuth协议的优势。 |
44 | 48 |
|
45 | 49 | #### OAuth 2.0授权流程
|
46 | 50 |
|
@@ -112,8 +116,7 @@ INSTALLED_APPS = [
|
112 | 116 | 自定义装饰器实现查询结果的缓存。
|
113 | 117 |
|
114 | 118 | ```Python
|
115 |
| -from pickle import dumps |
116 |
| -from pickle import loads |
| 119 | +from pickle import dumps, loads |
117 | 120 |
|
118 | 121 | from django.core.cache import caches
|
119 | 122 |
|
@@ -302,14 +305,14 @@ if alipay.verify(params, params.pop('sign')):
|
302 | 305 | 1. 秒杀:秒杀是通常意味着要在很短的时间处理极高的并发,系统在短时间需要承受平时百倍以上的流量,因此秒杀架构是一个比较复杂的问题,其核心思路是流量控制和性能优化,需要从前端(通过JavaScript实现倒计时、避免重复提交和限制频繁刷新)到后台各个环节的配合。流量控制主要是限制只有少部分流量进入服务后端(毕竟最终只有少部分用户能够秒杀成功),同时在物理架构上使用缓存(一方面是因为读操作多写操作少;另外可以将库存放在Redis中,利用DECR原语实现减库存;同时也可以利用Redis来进行限流,道理跟限制频繁发送手机验证码是一样的)和消息队列(消息队列最为重要的作用就是“削峰”和“上下游节点解耦合”)来进行优化;此外还要采用无状态服务设计,这样才便于进行水平扩展(通过增加设备来为系统扩容)。
|
303 | 306 | 2. 超卖现象:比如某商品的库存为1,此时用户1和用户2并发购买该商品,用户1提交订单后该商品的库存被修改为0,而此时用户2并不知道的情况下提交订单,该商品的库存再次被修改为-1这就是超卖现象。解决超卖现象有三种常见的思路:
|
304 | 307 | - 悲观锁控制:查询商品数量的时候就用`select ... for update`对数据加锁,这样的话用户1查询库存时,用户2因无法读取库存数量被阻塞,直到用户1提交或者回滚了更新库存的操作后才能继续,从而解决了超卖问题。但是这种做法对并发访问量很高的商品来说性能太过糟糕,实际开发中可以在库存小于某个值时才考虑加锁,但是总的来说这种做法不太可取。
|
305 |
| - - 乐观锁控制:查询商品数量不用加锁,更新库存的时候设定商品数量必须与之前查询数量相同才能更新,否则说明其他事务已经更新了库存,必须重新发出请求。这种做法要求事务隔离级别为可重复读,否则仍然会产生问题。 |
306 |
| - - 尝试减库存:将上面的查询(`select`)和更新(`update`)操作合并为一条SQL操作,更新库存的时候,在`where`筛选条件中加上`库存>=购买数量`或`库存-购买数量>=0`的条件。 |
| 308 | + - 乐观锁控制:查询商品数量不用加锁,更新库存的时候设定商品数量必须与之前查询数量相同才能更新,否则说明其他事务已经更新了库存,必须重新发出请求。这种做法要求事务隔离级别为可重复读(repeatable read),否则仍然会产生问题。 |
| 309 | + - 尝试减库存:将上面的查询(`select`)和更新(`update`)操作合并为一条SQL操作,更新库存的时候,在`where`筛选条件中加上`库存>=购买数量`或`库存-购买数量>=0`的条件,这种做法要求事务隔离级别为读提交(read committed)。 |
307 | 310 |
|
308 | 311 | > 提示:有兴趣的可以自己在知乎上看看关于这类问题的讨论。
|
309 | 312 |
|
310 | 313 | ### 静态资源管理
|
311 | 314 |
|
312 |
| -静态资源的管理可以自己架设文件服务器或者分布式文件服务器(FastDFS),但是一般的项目中没有必要这样做而且效果未必是最好的,我们建议使用云存储服务来管理网站的静态资源,国内外的云服务提供商如亚马逊、阿里云、腾讯云、七牛、LeanCloud、Bmob等都提供了非常优质的云存储服务,而且价格也是一般公司可以接受的。可以参考《在阿里云OSS上托管静态网站》一文来完成对网站静态资源的管理,代码相关的内容可以参考阿里云的[对象存储 OSS开发人员指南](https://www.alibabacloud.com/zh/support/developer-resources)。 |
| 315 | +静态资源的管理可以自己架设文件服务器或者分布式文件服务器(FastDFS),但是一般的项目中没有必要这样做而且效果未必是最好的,我们建议使用云存储服务来管理网站的静态资源,国内外的云服务提供商如[亚马逊](<https://amazonaws-china.com/cn/>)、[阿里云](<https://www.aliyun.com/product/oss>)、[七牛](<https://www.qiniu.com/products/kodo>)、[LeanCloud](<https://leancloud.cn/storage/>)、[Bmob](<https://www.bmob.cn/cloud>)等都提供了非常优质的云存储服务,而且价格也是一般公司可以接受的,具体的操作可以参考官方文档,例如:阿里云的[对象存储 OSS开发人员指南](https://www.alibabacloud.com/zh/support/developer-resources)。 |
313 | 316 |
|
314 | 317 | ### 全文检索
|
315 | 318 |
|
|
0 commit comments