返回信息流最近挖坟了
https://bbs.byr.cn/#!article/Python/1859
https://bbs.byr.cn/#!article/Python/6763
于是心头一热，顺手花了2天时间撸了一个图集小站，目前前端的异步加载样式还有点问题，欢迎来看?
http://51juchang.com/site/index/
规规矩矩按照套路，先分享下设计框架
基础组件：
HTTP服务，部署BAE一台机器
Nginx
python-Flask框架 + supervisor守护
MySQL、redis
前端bootstrap+jquery
微信订阅号
产品设计：
1.列表页支持无限刷新，最好有访问历史，以及去重。
实际上Web不像app，难以拿到user_id或device_id等用户标识，除非主动以微信用户ID为标识，但不全。
鉴于样本量已经大了，索性先随机混排。（应该有办法，求教）
2.详情页除了披露图集全量数据，下发相关推荐位=列表页，用户不必每次返回列表页再下翻。
模块设计：
爬取模块 + API模块 + 订阅号
定时脚本每天爬取图片，但没有申请图片cdn，偷懒直接存了源站图片URI，落地到MySQL。
（细节：通过nginx反向代理302到源站图片地址。注意通过referer的处理尽可能避免403等盗链。。我是不是太穷太坏了）
API模块提供3个接口：
1. 列表页主页面框架，用于渲染前端样式
2. 列表页图集数据接口，用于异步拉数据
3. 详情页页面，用于披露图集详细数据
（细节：cache+db，用redis缓存db数据，有过期时间；访问次数记录redis，粗略以send为准，没有靠前端埋点触发show事件）
订阅号完全是多年尘封的号，简单修改了下，发现微信对权限更加严格，订阅号已经不支持button跳转url了=。=
想到几点待改善：
能够有办法标识用户身份，可以做访问历史，去重，收藏等
考虑数据变化可能性小，可全量cache到redis，或者设置较长过期时间。
详情页偷懒直接渲染所有图片，可能导致加载图片时间较长，后面可做成异步部分加载。
增加搜索，基于elasticsearch倒排匹配，后面有空加吧。
前端异步加载样式有点问题，不会前端也没搞好。
整个设计和实现比较简单，很弱的单机器实例，抗不了多少qps，理想是基础组件拆分部署，db读写分离，db零穿透，nginx负载均衡，落地图片CDN。。。（所有这些都需要机器，需要money啊。。突然感觉能操作公司成百上千机器好富有=。=）
这是一条镜像帖。来源：北邮人论坛 / python / #17514同步于 2017/3/16
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Python机器人发帖
用python撸了一个图集小站
sunbird
2017/3/16镜像同步4 回复
订阅后，新回复会通过你的通知中心匿名送达。