微信网页音频播放遇到的坑(referer防盗链)

最近做微信网页开发,遇到音频问题。方案是在微信网页中,判断用户有收听权限的情况下,让他可以播放音频。在HTML中用了audio标签,用少量js代码控制播放。mp3文件来源是托管在阿里云cdn上面的。

昨天上午刚刚把cdn部署好,测试访问没问题。昨天晚上将带有音频播放功能的网页给用户开放,结果很多用户反应打开不了。明明自己在安卓、苹果上面都测试过了,怎么回事呢。一开始以为是mp3文件的比特率问题。到最后发现不是,后来抱着试试看的心理,清除了cdn里面的防盗链设置
继续阅读“微信网页音频播放遇到的坑(referer防盗链)”

阿里云CDN使用初探

CDN的基本原理,实际上是将某“加速域名”用CName解析到阿里云的DNS调度服务器,然后再只能分配到离访问用户最近的CDN节点。

加速域名就是你希望最终用户访问的域名,当然是希望该域名下的内容是经过了CDN加速的。

阿里云CDN节点事先没有你网站要提供的文件的,那么加速域名下的内容从何而来,就需要有一个源站,顾名思义,即内容的来源的意思。

举例来说,你希望网站 http://www.anrrzh.com 的所有内容都经过加速,那么就配置加速域名为该域名,而源站的配置方式上,有一个比较tricky的地方,是不管你设置为域名还是ip,都会解析成ip地址访问回去.

这里就涉及到一个很有意思的问题,在阿里云CDN文档中也并没有表述清楚的。那就是回源的请求虽然能以ip地址命中目标机器,但其访问的host信息,其实是可以配置的。源站设成某个域名,回源请求肯定会发回该域名指向的ip,但访问的http头信息中host未必为这个域名。在阿里云cdn管理控制台,还有回源host这项设置,可以指定回源请求以什么host访问。

这一点之所以重要,是因为事关源站服务器的解析,尤其是当源站涉及多站点虚拟主机的配置的时候。源站服务器上,也需要配置回源host所指定域名相应的虚拟主机的解析。

关于数据库主键设计

最近要做一些系统的开发,说实话也是有些年没有在一线工作了,动手的激情和乐趣感觉慢慢的回来了。

系统是一个与微信公众平台有交互的课程系统。由于既要支持微信用户登录,又要支持其他注册登录方式,因此要自己设计会员系统。在做数据库设计的时候,一开始像多年前一样,第一反应是给每张表一个自增长数字id作为唯一标识。但总觉得哪里不太妥。于是决定重新思考这个以前认为是最佳实践的原则,参考了一些文档,得出如下结论:

1,自增长需要等待返回值才能知道主键的具体值,对于多表关联的情况,需要等主键生成后再插入该值到关联表中作为外键,程序逻辑变成了两步插入,不太方便。因此主键最好能预先赋值;(本例中会员ID要更新到微信openid与会员关系的映射表)

2,多系统数据库整合的时候,如果大家都是用自增长,那么很难保证唯一性,当值冲突的时候很麻烦。因此主键最好全局(全世界)唯一;(本例中要考虑未来与第三方的开源微信系统如weiphp或者we7等整合)

3,要满足以上要求,多半需要字符串型字段作为主键;

4,要考虑索引性能;

5,是否要考虑后生成的主键值要比之前的大,还需要再考虑。

基本确定采用字符串型的主键,能预先赋值,且能保证全局唯一性,兼顾性能。暂定GUID方案。

其实在考虑以上问题之前还有一个先确定用业务字段还是非业务字段做主键的问题。如果是选择了非业务字段做主键,再考虑主键的生成方案。其实关于用业务字段还是无意义的非业务字段做主键也有很多争论,其中有一个观点认为:非业务字段做主键也是有缺点的,很多查询语句会变得复杂很多。我是挺同意的。当然业务字段做主键则需要放置业务规则发生变化。

本例中的用户ID字段,属于本系统新增的内容,其对应的业务字段来源有多种,除了微信用户openid可能还有其他第三方的用户标识,不能保证唯一性且不排除有变化的可能,所以只能选择非业务字段。从而才有了上面的选择该字段生成方式的问题。

请参考:

博客:数据库主键的设计和思考

知乎:使用自增主键是否总是最佳实践?

segmentfault: 在数据库设计中,无论如何也该设计一个自增ID字段作为主键吗?