无用挂件の日记

俯仰自得,游心太玄


Explore Me
无用挂件
无用挂件
逐梦不息的咸鱼一只
20
1
0
Google,Welcome Back!
随笔 无用挂件 · 1周前

八年,Google终于回归。

和多年前的那场匆匆离去相比,今日Google的回归显得相当之热闹。党报亲自发声欢迎,倒也是荣幸。

Google is welcome to return to China but only if it complies with the law.

"前提是必须遵守当地法律",此言一出,立即为中国舆论奠定了基调。无论是百度的战书还是腾讯的问卷,这句话总是显眼地摆在那边,正确性、权威性无可动摇。一时间,Google似乎成了就是那个干了违法勾当而被轰出家门的孩子,现在又恬不知耻地回来蹭饭吃。语言文字的高妙,在此淋漓毕现。

自然,法律是要遵守的,任何个人或组织都必须在国法下低头。国家法律中规定了网络审查,那么公开透明、民心所向的网络审查和封锁就必须矢志不移地推进。Apple蔑视FBI又怎样,必须和GCBD合作;Github上有严重影响社会长治久安的翻%墙项目,那么就必须删除。

因为我们是社会主义国家,所以我们必须伟大;因为我们是中华民族,所以我们必须复兴。我们提高了世界互联网的接入率,又创造了连绵万里的防火长城,区区资本主义市场必须听我们的。

我们从不搞黑客攻击,Github遭受1.35Gbps攻击纯属咎由自取;我们还是世界上黑客攻击的最大受害国,2014年某日下午全国性的根域服务器污染就是境外反华组织一手造出的好事。DNS污染?IP封杀?HTTP重置?中间人攻击?在锐意革新精神的指导下,这就是我们创造的抵御境外势力渗透的利刃,我们不愧为伟大的、傲然屹立于世界的中华民族。

个人之见看来,Google此次宣布回归定位相当精准。科%学%上%网活动大都转入地下活动,并呈日渐式微之势,Google Search将为有需求人群打上一针强心剂。Bing就为Google开了一个好头,强制开启安全搜索最严格模式,以积极主动的姿态拥抱法律监管。Google Play、Google Maps、Google Chrome、Gmail等早有定评的产品将让竞争对手认识到什么是优秀,而Google Drive、YouTube、Google+等业务应该长期不能进入大陆,上面大量的资本主义毒瘤亟待肃清。

真是一片大好前景。

8月,你好
随笔 无用挂件 · 2周前

7月过得...怎么说,还是很充实的。
(首先从我没时间写日记这点就能看出)
疲惫大抵是有点的罢,但是昨天去打了暑假以来的第一场羽毛球,晚上又看世锦赛,瞬间有种满血复活的感觉。
很好。

总结一下7月的生活:

8月,是努力的最后一点机会。
大难临头?还是准备收割?

莫名想起了这句:
So we beat on, boats against the current, borne back ceaselessly into the past.
那...就这样吧。

重建手札
随笔 无用挂件 · 1月前

先前因为某些原因,Blog遭到攻击并造成了一定的DNS缓存污染,于是关站了近一个月。
重建工作是在考拉的iPad Pro上完成的,很快,不到一刻钟就搞定了。
(也许创下了记录?)
新节点托管在香港沙田某IDC的BGP数据中心,CN2接入,响应还算可以。只是没有防御,怕是一打就要垮。
这么长时间没写Blog,但我从未中断过对自己的反思。如此,写日记的意义也就达到了。
Cloudflare CDN目前在国内基本上是已经没法用了。建过的几个站,DNS&CDN都托管在Cloudflare,确实功能也是很强大,用起来也是很方便,所以摆脱Cf还是需要一点点智慧的:)
所以再记点什么,以便参考。


SSL相关
Cloudflare的General SSL还是相当好用的,自带的一键开启HSTS更是懒人必备。所以不用Cloudflare SSL之后,这反而成了个问题。
raspii.tech目前采用的是TrustAsia ECC证书,看起来还行。不用Let's Encrypt的原因,大概是其给我带来了种滥发证书的感觉(尽管其后台大得很,Mozilla、Google都无条件支持)
HSTS也好解决。header.php里面在返回数据前加一行就行:

header("Strict-Transport-Security: max-age=63072000; includeSubdomains; preload");

CDN相关
Cloudflare提供了大量优化和缓存功能,缺了这个会很麻烦。
对于我这样的CN2节点,速度和响应倒不成问题。图片嘛,用sm.ms外链就好。

'Ready Player One' 观影体验
随笔 无用挂件 · 1月前

严格来讲,说成是“观影体验”并不靠谱,因为我是在家抱着ThinkPad的低分TN烂屏看的。
但这并不折损这部电影魅力半点,反而让我对Steven Spielberg更加地崇拜。
'The reality is the only thing that's real.'
That's it.

Redis VS Memcached?
随笔 无用挂件 · 1月前

建站初期,服务器上Redis和Memcached都装了,然而大部分插件都忽略了这两者的存在,直接写缓存进MySQL了==
两者都开对服务器还是有一定负担的,所以很有必要比较一下。
我的ThinkPad笔记本上安装的是Redis,当时看中了其数据持久化和多数据结构的特点,用下来感觉也还可以。
但是对于一个面向Web的I/O应用,我们似乎应该从不同的角度去思考。


面向Web的IO模型?
基于非阻塞IO复用的网络模型设计的Memcached有个好,多线程(监听主线程+worker子线程)充分发挥了多核优势,其性能不必多言。
而Redis使用单线程的IO复用模型,单线程可以将速度优势发挥到最大,但在排序、聚合等操作中,单线程会严重影响整体吞吐量。CPU计算过程中,整个IO调度都是被阻塞的。


内存管理机制?
Memcached使用预分配的内存池的方式,Redis使用现场申请内存的方式来存储数据。显然,Redis更适合作为存储而不是cache。


数据一致性问题?
Memcached提供了cas命令,可以保证多个并发访问操作同一份数据的一致性问题。
Redis没有提供cas命令,但提供了“事务”的功能,可以保证一串命令中间不会被任何操作打断。


集群管理?
Memcached本身并不支持分布式,因此只能在客户端通过像一致性Hash这样的分布式算法来实现分布式存储。
Redis更偏向于在服务器端构建分布式存储,支持了分布式存储功能。


结论:对于我那低性能小内存的服务器,Memcached看起来更加适合I/O网络应用。