我之前突然就很爱思考，尤其爱躺下准备睡觉前想想人类，想想宇宙，想想睡眠本身。最后突然竟然就怎么都睡不着了。再后来连续几天彻夜失眠，害怕至极，查了知乎发现一个神答案。从那以后闭眼几乎就能睡着。 我觉得这个答案太神了，不仅能被我用，也许以后还能给我的孩子用。。。[捂脸 我是多么的爱操心]收藏了真怕以后答案被删了，改了，或者知乎出现变故（别打我）而找不到了，所以特此复制一遍。

原文链接：
https://www.zhihu.com/question/29764256/answer/46646576

复制原文内容：

作者：肖遥生
链接：https://www.zhihu.com/question/29764256/answer/46646576
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

你每天11点就上了床，有时候还吃点药，打算11点半至12点间睡觉，拿起手机刷了刷，快到12点了，似乎没什么倦意，放下手机，进入睡眠状态，可是脑细胞更活跃了，一幕一幕跟放电影似的，“努力”睡了一会儿，睡不着，算了还是继续看手机吧，到了一两点，终于有些困意了，握着手机睡着了，结果中间醒了过来，一看手机，才三四点，并且异常清醒，瞬间泪崩……

失眠的人，或多或少都有过这种遭遇。

普鲁斯特也是如此，《追忆似水年华》七大卷开篇就说，「好久了，我一直早睡。有时，蜡烛刚灭，我的双眼随机闭上，快得来不及思量：“我睡了”。半小时后，我想到应该睡着了，这个想法反倒把我弄醒了」。

可我知道，你绝对不会像这位文学大师一样，仅仅因为睡前妈妈没来道声晚安就辗转难眠；你也不会像这位内心敏感的忧郁少年一样，将自己失眠的经历写成30页的日记。

更何况，如果你很多时候只是因为白天起得晚，然后在正常时段无法入睡了，便不必庸人自扰，那不叫失眠。

真正的失眠，是本来就起得早，也忙活了一天，本该早早累趴，进入梦乡，却陷入一开始提到的那番境遇。

问题是：我们为什么会失眠？

生活压力大引起的焦虑固然是最普遍的因素，但毕竟它只是外部原因，根源在于我们自己的内心。

睡觉是一项自然的身体活动，不是欲想的行为，不是发挥主观能动性的行动，是身体释放出的一段段流水似的、井然有序的感觉，告诉你，哦，困了，你也不带任何思绪地接受了，便睡着了；而不是心理活动，跟挂了个闹钟似的，不断催你，该睡了！该睡了！该睡了！每隔5分钟催1次，这要能睡得着那就是见了鬼了，往往是适得其反，换来越“想睡”越睡不着的遭遇。

所以失眠的问题出在：你只是“想睡”，心理活动上的“想睡”，身体却没有任何“想睡”的意思。“想”大大多于“自然的困意”，于是失眠开始了。

印度哲学家奥修也说，「人们认为他们无法入睡，人们认为他们的身体没有什么不对劲。他们的身体并没有什么不对劲。他们的身体跟以前一样健康，事实上比以前更健康，但是有某些东西深深地进入了他们的头脑：他们认为他们必须去做每一件事，然而睡觉时不能够被做的，那不是“做”的一部分，你必须“让”它睡，你无法做它，它不是一项行动；睡觉是自动来临的，它是一种发生。」

平日里的生活太紧绷了，太不自然了，遇到睡觉这样“自然”的事情，紧绷自然成了恶性循环的罪魁祸首。

放不下的事情太多了，郁结在脑海各个角落，白天，尚有其他事务填充大脑，暂时掩盖放不下的种种。一到夜深人静，身体、心灵卸下了一切防备，无处安放的思绪开始翻滚绞痛，不安宁了。

想睡+紧绷+放不下的种种，真乃失眠标配三件套了。

既然想睡又睡不了，那就别睡了；既然紧绷又放不下，那就做点别的事情，把不安分的因素赶走。

不妨拿起一本书看看。《存在与虚无》固然算得上催眠利器，但我估计你没看几个字思绪就跑到九霄云外了；《2666》固然能用大量离奇的情节满足你的猎奇心理，但我估计你的耐心遇到一整块一整块、一大段一大段、就是不另起一行的文字时，便默默认输了；《肉蒲团秘本》固然吸引人，但我怕你看了会做别的事，让人兴奋的事。

就看些带点温度的小说。像什么，《牧羊少年奇幻之旅》《通向蜘蛛巢的小径》《安吉拉·卡特的精怪故事集》《吉卜林动物小说》《泛若不系之舟》《快乐王子》《厨房》《罗生门》《面纱》《蜘蛛女之吻》《根西岛文学与土豆皮馅饼俱乐部》《一个人的朝圣》，就挺好的。

最好不要用手机或Kindle看，以免刚一睡着，手一松，利器把自己砸醒……

你开始慢慢放下种种，思绪化作一小束精神体，跟随作者的笔触进入故事的脉络，在里面惬意游走，徜徉，偶尔开个小差，再平缓地拉回来，累了，文字自然不会强拽着你继续翱翔，它在你思绪渐渐停滞的时候，便欣然放手。你只需不费力气地放下书本，顺应身体的信号，便安然入眠了。

“数羊”的本质也是如此——不让你胡思乱想，打断你过于猛烈的“想睡”的念头。不过你要是边数边想着这羊的品种、长什么样，这羊毛的手感、软不软，这羊的肥瘦、好吃不好吃，越数越兴奋，那就没救了。

一句话，让身体重回“自然”，丢掉细枝末节，忘却庸人自扰。一切由宁静而生，一切归于宁静。

这篇真的好全啊。。。

http://docs.celeryproject.org/en/latest/django/first-steps-with-django.html

这里就不禁想好好讲讲celery，其实是 Advanced Message Queueing Protocol (AMQP) 了。我自己也是参考了文章 https://www.abhishek-tiwari.com/amqp-rabbitmq-and-celery-a-visual-guide-for-dummies/ 和 https://www.cloudamqp.com/blog/2015-09-03-part4-rabbitmq-for-beginners-exchanges-routing-keys-bindings.html

再次感谢网络上这么多大神分享的这么多好的文章。很多原理都是在网上看了很多文章琢磨和理解透彻的。

生产者

生产者就是主业务服务里，产生异步消息或者任务的角色。生产者产生消息任务以后就需要下一个角色 Broker来发挥作用了。

Broker

Broker由 Exchange，Binding 和 Queue 组成。（我们最早用redis做Broker。）Broker主要用来接收和存储生产者发出的消息任务 —— Exchange会接收消息任务，通过Bindings等因素分发给某些Queue，然后消息任务会存储在被选择的Queue里。

Exchange是一个消息分发代理，会根据Bindings，消息的 header attributes, routing keys，决定什么消息任务进什么队列。

Binding其实就是Exchange和Queue之间的link。

我们可以配置多个Queue，每个队列有自己的binding key。

当一条消息任务发来后，这个任务会被打上一个routing key。而Exchange会把消息任务分发给和这个routing key完全一致的binding key的队列。

消费者

消费者由很多Workers组成。每个worker也可以起多个并发进程。每个worker会根据自己被配置的routing key对应的Queue去获取任务并执行。

Exchange Types

本文主要来源于django官方文档

原理是：given a URL, try finding that page in the cache

1
2
3
4
5
6

if the page is in the cache:
    return the cached page
else:
    generate the page
    save the generated page in the cache (for next time)
    return the generated page

先需要几步setup，决定cache存在哪，比如存在数据库，或文件系统，或内存。但是因为配置内容太多，觉得放在文章后面额部分。点此调到后方cache配置

所以这里先说一下我们实际写代码中最常用的用法 —— cache一个page

1
2
3
4

from django.views.decorators.cache import cache_page, never_cache
@cache_page(60 * 15)
def my_view(request):

cache_page 中传入的参数是timeout，单位是秒，源码当中核心就是

1
2
3
4

def cache_page(*args, **kwargs):
    return decorator_from_middleware_with_args(CacheMiddleware)(
        cache_timeout=cache_timeout, cache_alias=cache_alias, key_prefix=key_prefix
    )

实际发现如果设置了max_age，max_age的级别更高会覆盖timeout，所以普通使用的时候只设置timeout就好（我们猜想这么设计是为了给浏览器的数据和后台server cache失效时间要一致，因为max-age应该是给浏览器用的）

(此处源码在 django/middleware/cache.py:)

1
2
3
4
5
6

class UpdateCacheMiddleware(object):
    def process_response(self, request, response):
        '''此处省略很多代码'''
        timeout = get_max_age(response)
        if timeout is None:
            timeout = self.cache_timeout

never_cache也是很好用的一个decorator，相当于把各种参数都设置成不缓存，就是以下效果

‘cache-control’: ‘no-cache’

还可以较底层的使用方法

1
2

from django.core.cache import caches
cache1 = caches['myalias']

这样就得到了一个cache的instance。如果不想指明，可以用默认的cache instance：

1

from django.core.cache import cache

这个cache instance相当于是caches[‘default’]。
cache的数据结构就是键值对儿，所以用法是 set(key, value, timeout) 和 get(key)。

1
2

cache.set('my_key', 'my_value', 30)
cache.get('my_key')

cache还有很多方法，比如add，get_or_set，delete等，具体都可以见Django官方文档。

当一个key并不存在的时候，cache.get(key)会返回None。因为这样，官方强烈建议大家不要在cache里存值本身就为None的条目，因为这样拿到None的时候会混淆。

Cache key

为了区分不同的环境或者服务器等（developping env, production env）可以给cache加个前缀 - settings里cache的配置加上KEY_PREFIX。
每一个cache还可以有版本，比如

1
2

cache.set('my_key', 'hello world!', version=2)
cache.get('my_key', version=2)

综合来说要得到一个cache完成的key，源码是

1
2

def make_key(key, key_prefix, version):
    return ':'.join([key_prefix, str(version), key])

可以写自己自定义得到解析cache key的方法，比如把key做哈希

Cache的配置有以下几种

Memcached

memcached 的所有数据都会存在内存上，所以不会出现向数据库或文件系统溢出的问题。它会运行在后台（类似守护进程）并被分配一定量的ram（内存）
可以起多个instance并且配置：

1
2
3
4
5
6
7
8
9
10

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': [
            '172.19.26.240:11211',
            '172.19.26.242:11212',
            '172.19.26.244:11213',
        ]
    }
}

缺点是没有数据持久性，

Database caching

1
2
3
4
5
6

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',
    }
}

用数据库做cache的时候必须先

1

python manage.py createcachetable

表名就是location的值

Filesystem caching

1
2
3
4
5
6

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',
    }
}

location should be an absolute path

Local-memory caching

如果没有任何setting，这个cache是default的。 如果没有足够的性能去用memcached，可以选择这个。它的instance基于单个进程，并且是线程安全的。

1
2
3
4
5
6

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'unique-snowflake',
    }
}

因为跨进程是不可能的，这种最好适用于开发环境，而不是生产环境

Dummy caching

啥都不干。。。只是可以用所有的cache接口。专为了开发环境。

1
2
3
4
5

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
    }
}

Settings中Middleware的顺序

最后说一下在settings中，如果要用cache的middleware，需要注意放置的顺序。

我们常看到settings中的middleware settings是类似这样：

1
2
3
4
5
6
7
8
9
10
11
12
13

MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'corsheaders.middleware.CorsMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'django.middleware.security.SecurityMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
)

首先要明确middleware的执行规则 - 官方文档1.11

Middleware是Django的request/response的钩子，在request请求中，执行到view之前，middleware的执行顺序是和代码中一样从上至下的。而在开始响应response的时候，middleware的执行是从下至上的（所谓的”the way back”）。如果某一层要短路的话，之后的层都不会接到任何request或response。官方文档中把middleware这种顺序比喻成一个洋葱从最外层到最内层再返回，如果一个钩子执行到了洋葱的某一层就往外返回了，洋葱里面的那些层是完全无感知的。

再看回cache相关的middleware，主要是django.middleware.cache.UpdateCacheMiddleware和django.middleware.cache.FetchFromCacheMiddleware。UpdateCacheMiddleware是在response层面执行，所以要确保它在一些会修改header的middleware之后运行，所以一般把它放最上面。而FetchFromCacheMiddleware是在request层面执行，它一样需要在可能更改header的middleware之后运行，所以可以把它放在最下面。

Welcome to Ella’s space! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

开始写博客吧！XD