EXPIRE key seconds

Set a timeout on 


. After the timeout has expired, the key will automatically be deleted. A key with an associated timeout is often said to be volatile in Redis terminology.

The timeout will only be cleared by commands that delete or overwrite the contents of the key, including DELSETGETSET and all the 


commands. This means that all the operations that conceptually alter the value stored at the key without replacing it with a new one will leave the timeout untouched. For instance, incrementing the value of a key with INCR, pushing a new value into a list with LPUSH, or altering the field value of a hash with HSET are all operations that will leave the timeout untouched.

The timeout can also be cleared, turning the key back into a persistent key, using the PERSIST command.

If a key is renamed with RENAME, the associated time to live is transferred to the new key name.

If a key is overwritten by RENAME, like in the case of an existing key 


that is overwritten by a call like 


, it does not matter if the original 


 had a timeout associated or not, the new key 


 will inherit all the characteristics of 



Note that calling EXPIRE/PEXPIRE with a non-positive timeout orEXPIREAT/PEXPIREAT with a time in the past will result in the key beingdeleted rather than expired (accordingly, the emitted key event will be 


, not 



Refreshing expires

It is possible to call EXPIRE using as argument a key that already has an existing expire set. In this case the time to live of a key is updated to the new value. There are many useful applications for this, an example is documented in the Navigation session pattern section below.

Differences in Redis prior 2.1.3

In Redis versions prior 2.1.3 altering a key with an expire set using a command altering its value had the effect of removing the key entirely. This semantics was needed because of limitations in the replication layer that are now fixed.

EXPIRE would return 0 and not alter the timeout for a key with a timeout set.

Return value

Integer reply, specifically:

  • 1

     if the timeout was set.

  • 0



     does not exist.


redis> SET mykey “Hello”


redis> EXPIRE mykey 10

(integer) 1

redis> TTL mykey

(integer) 10

redis> SET mykey “Hello World”


redis> TTL mykey

(integer) -1

Pattern: Navigation session

Imagine you have a web service and you are interested in the latest N pagesrecently visited by your users, such that each adjacent page view was not performed more than 60 seconds after the previous. Conceptually you may consider this set of page views as a Navigation session of your user, that may contain interesting information about what kind of products he or she is looking for currently, so that you can recommend related products.

You can easily model this pattern in Redis using the following strategy: every time the user does a page view you call the following commands:

RPUSH pagewviews.user:<userid> http://.....
EXPIRE pagewviews.user:<userid> 60

If the user will be idle more than 60 seconds, the key will be deleted and only subsequent page views that have less than 60 seconds of difference will be recorded.

This pattern is easily modified to use counters using INCR instead of lists using RPUSH.

Appendix: Redis expires

Keys with an expire

Normally Redis keys are created without an associated time to live. The key will simply live forever, unless it is removed by the user in an explicit way, for instance using the DEL command.

The EXPIRE family of commands is able to associate an expire to a given key, at the cost of some additional memory used by the key. When a key has an expire set, Redis will make sure to remove the key when the specified amount of time elapsed.

The key time to live can be updated or entirely removed using the EXPIREand PERSIST command (or other strictly related commands).

Expire accuracy

In Redis 2.4 the expire might not be pin-point accurate, and it could be between zero to one seconds out.

Since Redis 2.6 the expire error is from 0 to 1 milliseconds.

Expires and persistence

Keys expiring information is stored as absolute Unix timestamps (in milliseconds in case of Redis version 2.6 or greater). This means that the time is flowing even when the Redis instance is not active.

For expires to work well, the computer time must be taken stable. If you move an RDB file from two computers with a big desync in their clocks, funny things may happen (like all the keys loaded to be expired at loading time).

Even running instances will always check the computer clock, so for instance if you set a key with a time to live of 1000 seconds, and then set your computer time 2000 seconds in the future, the key will be expired immediately, instead of lasting for 1000 seconds.

How Redis expires keys

Redis keys are expired in two ways: a passive way, and an active way.

A key is passively expired simply when some client tries to access it, and the key is found to be timed out.

Of course this is not enough as there are expired keys that will never be accessed again. These keys should be expired anyway, so periodically Redis tests a few keys at random among keys with an expire set. All the keys that are already expired are deleted from the keyspace.

Specifically this is what Redis does 10 times per second:

  1. Test 20 random keys from the set of keys with an associated expire.
  2. Delete all the keys found expired.
  3. If more than 25% of keys were expired, start again from step 1.

This is a trivial probabilistic algorithm, basically the assumption is that our sample is representative of the whole key space, and we continue to expire until the percentage of keys that are likely to be expired is under 25%

This means that at any given moment the maximum amount of keys already expired that are using memory is at max equal to max amount of write operations per second divided by 4.

How expires are handled in the replication link and AOF file

In order to obtain a correct behavior without sacrificing consistency, when a key expires, a DEL operation is synthesized in both the AOF file and gains all the attached replicas nodes. This way the expiration process is centralized in the master instance, and there is no chance of consistency errors.

However while the replicas connected to a master will not expire keys independently (but will wait for the DEL coming from the master), they’ll still take the full state of the expires existing in the dataset, so when a replica is elected to master it will be able to expire the keys independently, fully acting as a master.

ubuntu下安装 mod_wsgi

1.pip install mod_wsgi
Collecting mod_wsgi
  Downloading mod_wsgi-4.5.18.tar.gz (2.5MB)
    100% |████████████████████████████████| 2.5MB 21kB/s 
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File “”, line 1, in
      File “/tmp/pip-build-lemsW_/mod-wsgi/setup.py”, line 164, in
        ‘missing Apache httpd server packages.’ % APXS)
    RuntimeError: The ‘apxs’ command appears not to be installed or is not executable. Please check the list of prerequisites in the documentation for this package and install any missing Apache httpd server packages.
Command “python setup.py egg_info” failed with error code 1 in /tmp/pip-build-lemsW_/mod-wsgi/
sudo apt-get install apache2-dev
well@well:/usr/local/lib$ sudo pip install mod_wsgi
The directory ‘/home/well/.cache/pip/http’ or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
The directory ‘/home/well/.cache/pip’ or its parent directory is not owned by the current user and caching wheels has been disabled. check the permissions and owner of that directory. If executing pip with sudo, you may want sudo’s -H flag.
Collecting mod_wsgi
  Downloading mod_wsgi-4.5.18.tar.gz (2.5MB)
    100% |████████████████████████████████| 2.5MB 47kB/s 
Installing collected packages: mod-wsgi
  Running setup.py install for mod-wsgi … done
Successfully installed mod-wsgi-4.5.18





$token_access_url = “https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&appid=此处为你的APPID&secret=此处为你的APP密码”;
$res = file_get_contents($token_access_url);
$result = json_decode($res, true); //接受一个 JSON 格式的字符串并且把它转换为 PHP 变量
$access_token = $result[‘access_token’];
// echo $access_token;

include_once ‘access_token_yuanshishuju.php’;//此处插入第一段获取access_token的php文件
include_once ‘coom.php’;//此处插入mysql连接设置文件
mysqli_query($conn , “set names utf8”);
$sql = “UPDATE 表名
SET 字段名= ‘$access_token’
WHERE id=1”;
mysqli_select_db( $conn, ‘数据库名’ );
$retval = mysqli_query( $conn, $sql );
if(! $retval )
die(‘无法更新数据: ‘ . mysqli_error($conn));
echo “数据更新成功\n”;
file_get_contents($url);//此处设置定时刷新,需打开一次该文件,打开后会一直显示刷新状态,然后关闭就行了 ,会一直自己运行,修改本文件后需再一次打开本文件,保证一直刷新

include_once ‘coom.php’;//数据库连接设置
mysqli_query($conn , “set names utf8”);
$sql = ‘SELECT 字段名
where id = 1’;
mysqli_select_db( $conn, ‘数据库名’ );
$retval = mysqli_query( $conn, $sql );
if(! $retval )
die(‘无法查询数据: ‘ . mysqli_error($conn));
$row = mysqli_fetch_array($retval, MYSQL_ASSOC);
$access_token = $row[‘access_token’];//获取该值
// echo $access_token;


Ubuntu 18.04 安装 Apache, MySQL, PHP7, phpMyAdmin


sudo apt update

sudo apt upgrade

sudo apt dist-upgrade

sudo apt install apache2

sudo apt install php

sudo apt install mysql-server php-mysql

mysql -u root
use mysql;
update mysql.user <span class=”hljs-built_in”>set</span> authentication_string=PASSWORD(<span class=”hljs-string”>’你的密码'</span>), plugin=<span class=”hljs-string”>’mysql_native_password'</span> <span class=”hljs-built_in”>where</span> user=<span class=”hljs-string”>’root'</span>;
flush privileges;
sudo service mysql stop
sudo service mysql start

sudo apt install libapache2-mod-php php-mysql php-curl php-gd

sudo apt install phpmyadmin

sudo a2enmod rewrite
sudo service apache2 restart

<Directory /var/www>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
RewriteEngine On

编辑 /etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
ServerAdmin service@example.com
DocumentRoot /var/www/example
<Directory />
DirectoryIndex index.html index.php
Options FollowSymLinks
AllowOverride All
RewriteEngine On
ErrorLog /var/log/apache2/example_error.log
CustomLog /var/log/apache2/example_access.log combined

sudo chown -R ubuntu /var/www/

chmod 755 /var/www/
chmod 777 /var/www/example/application
chmod 777 /var/www/example/uploads -R
chmod 777 /var/www/example/runtime -R


使用 pip 安装 TensorFlow

使用 pip 安装 TensorFlow

使用 pip 安装 TensorFlow

TensorFlow 2.0 Alpha 版现已推出

  • tensorflow==2.0.0-alpha0

     – 仅支持 CPU 的预览 TF 2.0 Alpha 版(不稳定)

  • tensorflow==2.0.0-alpha0-gpu

     – 支持 GPU 的预览 TF 2.0 Alpha 版(不稳定,适用于 Ubuntu 和 Windows)


  • tensorflow

     – 仅支持 CPU 的最新稳定版(适用于 Ubuntu 和 Windows)

  • tensorflow-gpu

     – 支持 GPU 的最新稳定版(适用于 Ubuntu 和 Windows)

  • tf-nightly

     – 仅支持 CPU 的预览每夜版(不稳定)

  • tf-nightly-gpu

     – 支持 GPU 的预览每夜版(不稳定,适用于 Ubuntu 和 Windows)


  • Ubuntu 16.04 或更高版本(64 位)
  • macOS 10.12.6 (Sierra) 或更高版本(64 位)(不支持 GPU)
  • Windows 7 或更高版本(64 位)(仅支持 Python 3)
  • Raspbian 9.0 或更高版本


  • 从 TensorFlow 1.6 开始,二进制文件使用 AVX 指令,这些指令可能无法在旧版 CPU 上运行。
  • 阅读 GPU 支持指南,以在 Ubuntu 或 Windows 上设置支持 CUDA® 的 GPU 卡。

1. 在系统上安装 Python 开发环境

 检查是否已配置 Python 环境:


<span class="pln">python3 </span><span class="pun">--</span><span class="pln">version</span>
<span class="pln">pip3 </span><span class="pun">--</span><span class="pln">version</span>
<span class="pln">virtualenv </span><span class="pun">--</span><span class="pln">version</span>

否则,请安装 Pythonpip 软件包管理器和 Virtualenv


<span class="pln">sudo apt update</span>
<span class="pln">sudo apt install python3</span><span class="pun">-</span><span class="pln">dev python3</span><span class="pun">-</span><span class="pln">pip</span>
<span class="pln">sudo pip3 install </span><span class="pun">-</span><span class="pln">U virtualenv  </span><span class="com"># system-wide install</span>

2. 创建虚拟环境(推荐)

Python 虚拟环境用于将软件包安装与系统隔离开来。

创建一个新的虚拟环境,方法是选择 Python 解析器并创建一个 



virtualenv --system-site-packages -p python3 ./venv

使用特定于 shell 的命令激活该虚拟环境:

source ./venv/bin/activate  # sh, bash, ksh, or zsh

当 virtualenv 处于有效状态时,shell 提示符带有 






<span class="pln">pip install </span><span class="pun">--</span><span class="pln">upgrade pip</span>
<span class="pln">pip list  </span><span class="com"># show packages installed within the virtual environment</span>

之后要退出 virtualenv,请使用以下命令:

deactivate  # don't exit until you're done using TensorFlow

3. 安装 TensorFlow pip 软件包

从 PyPI 中选择以下某个 TensorFlow 软件包进行安装:

  • tensorflow

     – 仅支持 CPU 的最新稳定版(建议新手使用)

  • tensorflow-gpu

     – 支持 GPU 的最新稳定版(适用于 Ubuntu 和 Windows)

  • tf-nightly

     – 仅支持 CPU 的预览每夜版(不稳定)

  • tf-nightly-gpu

     – 支持 GPU 的预览每夜版(不稳定,适用于 Ubuntu 和 Windows)

  • tensorflow==2.0.0-alpha0

     – 仅支持 CPU 的预览 TF 2.0 Alpha 版(不稳定)

  • tensorflow-gpu==2.0.0-alpha0

     – 支持 GPU 的预览 TF 2.0 Alpha 版(不稳定,Ubuntu 和 Windows)

pip install --upgrade tensorflow


python -c "import tensorflow as tf; tf.enable_eager_execution(); print(tf.reduce_sum(tf.random_normal([1000, 1000])))"


有几个安装机制需要您提供 TensorFlow Python 软件包的网址。您需要根据 Python 版本指定网址。

版本 网址
Python 2.7(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp27-none-linux_x86_64.whl
Python 2.7(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp27-none-linux_x86_64.whl
Python 3.4(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp34-cp34m-linux_x86_64.whl
Python 3.4(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp34-cp34m-linux_x86_64.whl
Python 3.5(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp35-cp35m-linux_x86_64.whl
Python 3.5(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp35-cp35m-linux_x86_64.whl
Python 3.6(仅支持 CPU) https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-1.12.0-cp36-cp36m-linux_x86_64.whl
Python 3.6(支持 GPU) https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow_gpu-1.12.0-cp36-cp36m-linux_x86_64.whl
macOS(仅支持 CPU)
Python 2.7 https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-1.12.0-py2-none-any.whl
Python 3.4、3.5、3.6 https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-1.12.0-py3-none-any.whl
Python 3.5(仅支持 CPU) https://storage.googleapis.com/tensorflow/windows/cpu/tensorflow-1.12.0-cp35-cp35m-win_amd64.whl
Python 3.5(支持 GPU) https://storage.googleapis.com/tensorflow/windows/gpu/tensorflow_gpu-1.12.0-cp35-cp35m-win_amd64.whl
Python 3.6(仅支持 CPU) https://storage.googleapis.com/tensorflow/windows/cpu/tensorflow-1.12.0-cp36-cp36m-win_amd64.whl
Python 3.6(支持 GPU) https://storage.googleapis.com/tensorflow/windows/gpu/tensorflow_gpu-1.12.0-cp36-cp36m-win_amd64.whl

FLASK + Apache + mod_wsgi + ubuntu18.04 部署笔记


1. 安装apache

sudo apt install apache2
sudo apt install apache2-dev

2. 安装pip3


sudo apt install python3-pip

3. 将mod_wsgi安装到python中

pip3 install mod_wsgi


4. 在apache中启用安装到python中的mod_wsgi


mod_wsgi-express module-config


LoadModule wsgi_module <span class="hljs-string">"/your/lib/python3.6/site-packages/mod_wsgi/server/mod_wsgi-py36.cpython-36m-x86_64-linux-gnu.so"</span>
WSGIPythonHome <span class="hljs-string">"/usr"</span>



nano /etc/apache2/mods-available/wsgi.load



sudo a2enmod wsgi
systemctl restart apache2

5 配置python虚拟环境


sudo apt install python3-venv


pyvenv path/to/venv/


6 编写






    <span class="hljs-keyword">import</span> sys
    sys.path.insert(<span class="hljs-number">0</span>, <span class="hljs-string">'/path/to/the/application'</span>)
     <span class="hljs-keyword">from</span> yourapplication <span class="hljs-keyword">import</span> app <span class="hljs-keyword">as</span> application

7 编写apache虚拟站点配置文件



nano /etc/apache2/site-available/yoursite.conf


<span class="hljs-tag">&lt;<span class="hljs-name">VirtualHost</span> *<span class="hljs-attr">:80</span>&gt;</span>
    ServerName example.com
    # python-home指定python虚拟目录的位置
    WSGIDaemonProcess yourapplication python-home=/path/to/env/
    WSGIScriptAlias / /path/to/yourapplication/yourapplication.wsgi
        <span class="hljs-tag">&lt;<span class="hljs-name">Directory</span> /<span class="hljs-attr">path</span>/<span class="hljs-attr">to</span>/<span class="hljs-attr">yourapplication</span>&gt;</span>
        WSGIProcessGroup yourapplication
        WSGIApplicationGroup %{GLOBAL}
        Require all granted
    <span class="hljs-tag">&lt;/<span class="hljs-name">Directory</span>&gt;</span>
<span class="hljs-tag">&lt;/<span class="hljs-name">VirtualHost</span>&gt;</span>

8 致此配置完毕,最后一点小问题


attempt to write a readonly database


sudo chown www-data your/database/
sudo chown www-data your/database/database

9 参考文章

  1. flask文档 http://flask.pocoo.org/docs/1.0/deploying/mod_wsgi/
  2. mod_wsgi文档 http://modwsgi.readthedocs.io/en/develop/project-status.html
  3. mod_wsgi pypi页面 https://pypi.org/project/mod_wsgi/
  4. 问题解决:SQLite:DatabaseError : attempt to write a readonly databas http://ju.outofmemory.cn/entry/147685


Configuration Guidelines

Configuration Guidelines

The purpose of this document is to detail the basic configuration steps required for running WSGI applications with mod_wsgi.

The WSGIScriptAlias Directive

Configuring Apache to run WSGI applications using mod_wsgi is similar to how Apache is configured to run CGI applications. To streamline this task however, an additional configuration directive called WSGIScriptAlias is provided. Like the ScriptAlias directive for CGI scripts, the mod_wsgi directive combines together a number of steps so as to reduce the amount of configuration required.

The first way of using the WSGIScriptAlias directive to indicate the WSGI application to be used, is to associate a WSGI application against a specific URL prefix:

WSGIScriptAlias /myapp /usr/local/wsgi/scripts/myapp.wsgi

The last option to the directive in this case must be a full pathname to the actual code file containing the WSGI application. A trailing slash should never be added to the last option when it is referring to an actual file.

The WSGI application contained within the code file specified should be called ‘application’. For example:

def application(environ, start_response):
    status = '200 OK'
    output = b'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

Note that an absolute pathname to a WSGI script file must be provided. It is not possible to specify an application by Python module name alone. A full path is used for a number of reasons, the main one being so that all the Apache access controls can still be applied to indicate who can actually access the WSGI application. Because these access controls will apply, if the WSGI application is located outside of any directories already known to Apache, it will be necessary to tell Apache that files within that directory can be used. To do this the Directory directive must be used:

<Directory /usr/local/wsgi/scripts>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

Note that Apache access control directives such as Order and Allow, or Require in the case of Apache 2.4 or newer, should nearly always be applied to Directory and never to a Location. Adding them to a Location would not be regarded as best practice and would potentially weaken the security of your Apache server, especially where the Location was for ‘/’.

As for CGI scripts and the ScriptAlias directive, it is not necessary to have used the Options directive to enable the ExecCGI directive. This is because it is automatically implied from the use of the WSGIScriptAlias directive that the script must be executable.

For WSGIScriptAlias, to mount a WSGI application at the root of the web site, simply use ‘/’ as the mount point:

WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi

If you need to mount multiple WSGI applications, the directives can be listed more than once. When this occurs, those occuring first are given precedence. As such, those which are mounted at what would be a sub URL to another WSGI application, should always be listed earlier:

WSGIScriptAlias /wiki /usr/local/wsgi/scripts/mywiki.wsgi
WSGIScriptAlias /blog /usr/local/wsgi/scripts/myblog.wsgi
WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi

The second way of using the WSGIScriptAlias directive is to use it to map to a directory containing any number of WSGI applications:

WSGIScriptAlias /wsgi/ /usr/local/wsgi/scripts/

When this is used, the next part of the URL after the URL prefix is used to identify which WSGI application script file within the target directory should be used. Both the mount point and the directory path must have a trailing slash.

If you want WSGI application scripts to use an extension, but don’t wish to have that extension appear in the URL, then it is possible to use the WSGIScriptAliasMatch directive instead:

WSGIScriptAliasMatch ^/wsgi/([^/]+) /usr/local/wsgi/scripts/$1.wsgi

In this case, any path information appearing after the URL prefix, will be mapped to a corresponding WSGI script file in the directory, but with a ‘.wsgi’ extension. The extension would though not need to be included in the URL.

In all ways that the WSGIScriptAlias can be used, the target script is not required to have any specific extension type and in particular it is not necessary to use a ‘.py’ extension just because it contains Python code. Because the target script is not treated exactly like a traditional Python module, if an extension is used, it is recommended that ‘.wsgi’ be used rather than ‘.py’.

The Apache Alias Directive

Although the WSGIScriptAlias directive is provided, the traditional Alias directive can still be used to enable execution of WSGI applications for specific URLs. The equivalent such configuration for:

WSGIScriptAlias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

using the Alias directive would be:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI

SetHandler wsgi-script

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

The additional steps required in this case are to enable the ability to execute CGI like scripts using the Options directive and define the Apache handler as ‘wsgi-script’.

If wishing to hold a mixture of static files, normal CGI scripts and WSGI applications within the one directory, the AddHandler directive can be used instead of the SetHandler directive to distinguish between the various resource types based on resource extension:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

For whatever extension you use to identify a WSGI script file, ensure that you do not have a conflicting definition for that extension marking it as a CGI script file. For example, if you previously had all ‘.py’ files being handled as ‘cgi-script’, consider disabling that before marking ‘.py’ file as then being handled as ‘wsgi-script’ file in same context. If both are defined in same context, which is used will depend on the order of the directives and the wrong handler may be selected.

Because an extension is required to determine whether a script should be processed as a CGI script versus a WSGI application, the extension would need to appear in the URL. If this is not desired, then add the MultiViews option and MultiviewsMatch directive:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI MultiViews
MultiviewsMatch Handlers

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

Adding of MultiViews in this instance and allowing multiviews to match Apache handlers will allow the extension to be dropped from the URL. Provided that for each resource there is only one alternative, Apache will then automatically select either the CGI script or WSGI application as appropriate for that resource. Use of multiviews in this way would make it possible to transparently migrate from CGI scripts to WSGI applications without the need to change any URLs.

A benefit of using the AddHandler directive as described above, is that it also allows a directory index page or directory browsing to be enabled for the directory. To enable directory browsing add the Indexes option:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI Indexes

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

If a directory index page is enabled, it may refer to either a static file, CGI or WSGI application. The DirectoryIndex directive should be used to designate what should be used for the index page:

Alias /wsgi/ /usr/local/wsgi/scripts/

<Directory /usr/local/wsgi/scripts>
Options ExecCGI Indexes

DirectoryIndex index.html index.wsgi index.cgi

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

Using AddHandler or SetHandler to configure a WSGI application can also be done from within the ‘.htaccess’ file located within the directory which a URL maps to. This will however only be possible where the directory has been enabled to allow these directives to be used. This would be done using the AllowOverride directive and enabling FileInfo for that directory. It would also be necessary to allow the execution of scripts using the Options directive by listing ExecCGI:

Alias /site/ /usr/local/wsgi/site/

<Directory /usr/local/wsgi/site>
AllowOverride FileInfo
Options ExecCGI MultiViews Indexes
MultiviewsMatch Handlers

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

This done, the ‘.htaccess’ file could then contain:

DirectoryIndex index.html index.wsgi index.cgi

AddHandler cgi-script .cgi
AddHandler wsgi-script .wsgi

Note that the DirectoryIndex directive can only be used to designate a simple WSGI application which returns a single page for when the URL maps to the actual directory. Because the DirectoryIndex directive is not applied when the URL has additional path information beyond the leading portion of the URL which mapped to the directory, it cannot be used as a means of making a complex WSGI application responding to numerous URLs appear at the root of a server.

When using the AddHandler directive, with WSGI applications identified by the extension of the script file, the only way to make the WSGI application appear as the root of the server is to perform on the fly rewriting of the URL internal to Apache using mod_rewrite. The required rules for mod_rewrite to ensure that a WSGI application, implemented by the script file ‘site.wsgi’ in the root directory of the virtual host, appears as being mounted on the root of the virtual host would be:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L]

Do note however that when the WSGI application is executed for a request the ‘SCRIPT_NAME’ variable indicating what the mount point of the application was will be ‘/site.wsgi’. This will mean that when a WSGI application constructs an absolute URL based on ‘SCRIPT_NAME’, it will include ‘site.wsgi’ in the URL rather than it being hidden. As this would probably be undesirable, many web frameworks provide an option to override what the value for the mount point is. If such a configuration option isn’t available, it is just as easy to adjust the value of ‘SCRIPT_NAME’ in the ‘site.wsgi’ script file itself:

def _application(environ, start_response):
    # The original application.

import posixpath

def application(environ, start_response):
    # Wrapper to set SCRIPT_NAME to actual mount point.
    environ['SCRIPT_NAME'] = posixpath.dirname(environ['SCRIPT_NAME'])
    if environ['SCRIPT_NAME'] == '/':
        environ['SCRIPT_NAME'] = ''
    return _application(environ, start_response)

This wrapper will ensure that ‘site.wsgi’ never appears in the URL as long as it wasn’t included in the first place and that access was always via the root of the web site instead.

Application Configuration

If it is necessary or desired to be able to pass configuration information through to a WSGI application from the Apache configuration file, then the SetEnv directive can be used:

WSGIScriptAlias / /usr/local/wsgi/scripts/demo.wsgi

SetEnv demo.templates /usr/local/wsgi/templates
SetEnv demo.mailhost mailhost
SetEnv demo.debugging 0

Any such variables added using the SetEnv directive will be automatically added to the WSGI environment passed to the application when executed.

Note that the WSGI environment is passed upon each request to the application in the ‘environ’ argument of the application object. This environment is totally unrelated to the process environment which is kept in ‘os.environ’. The SetEnv directive has no effect on ‘os.environ’ and there is no way through Apache configuration directives to affect what is in the process environment.

If needing to dynamically set variables based on some aspects of the request itself, the RewriteRule directive may also be useful in some cases as an avenue to set application configuration variables.

For example, to enable additional debug only when the client is connecting from the localhost, the following might be used:

SetEnv demo.debugging 0

RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^$
RewriteRule . - [E=demo.debugging:1]

More elaborate schemes involving RewriteMap could also be employed.

Where SetEnv and RewriteRule are insufficient, then any further application configuration should be injected into an application using a WSGI application wrapper within the WSGI application script file:

def _application(environ, start_response):

def application(environ, start_response):
    if environ['REMOTE_ADDR'] in ['']:
        environ['demo.debugging'] = '1'
    return _application(environ, start_response)

User Authentication

As is the case when using CGI scripts with Apache, authorisation headers are not passed through to WSGI applications. This is the case, as doing so could leak information about passwords through to a WSGI application which should not be able to see them when Apache is performing authorisation.

Unlike CGI scripts however, when using mod_wsgi, the WSGIPassAuthorization directive can be used to control whether HTTP authorisation headers are passed through to a WSGI application in the 

<span class="pre">HTTP_AUTHORIZATION</span>

 variable of the WSGI application environment when the equivalent HTTP request headers are present. This option would need to be set to 

<span class="pre">On</span>

 if the WSGI application was to handle authorisation rather than Apache doing it:

WSGIPassAuthorization On

If Apache is performing authorisation and not the WSGI application, a WSGI application can still find out what type of authorisation scheme was used by checking the variable 

<span class="pre">AUTH_TYPE</span>

 of the WSGI application environment. The login name of the authorised user can be determined by checking the variable 

<span class="pre">REMOTE_USER</span>


Hosting Of Static Files

When the WSGIScriptAlias directive is used to mount an application at the root of the web server for a host, all requests for that host will be processed by the WSGI application. If is desired for performance reasons to still use Apache to host static files associated with the application, then the Alias directive can be used to designate the files and directories which should be served in this way:

Alias /robots.txt /usr/local/wsgi/static/robots.txt
Alias /favicon.ico /usr/local/wsgi/static/favicon.ico

AliasMatch /([^/]*\.css) /usr/local/wsgi/static/styles/$1

Alias /media/ /usr/local/wsgi/static/media/

<Directory /usr/local/wsgi/static>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi

<Directory /usr/local/wsgi/scripts>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

When listing the directives, list those for more specific URLs first. In practice this shouldn’t actually be required as the Alias directive should take precedence over WSGIScriptAlias, but good practice all the same.

Do note though that if using Apache 1.3, the Alias directive will only take precedence over WSGIScriptAlias if the mod_wsgi module is loaded prior to the mod_alias module. To ensure this, the LoadModule/AddModule directives are used.

Note that there is never a need to use SetHandler to reset the Apache content handler back to ‘None’ for URLs mapped to static files. That this is a requirement for mod_python is a short coming in mod_python, do not do the same thing for mod_wsgi.

Limiting Request Content

By default Apache does not limit the amount of data that may be pushed to the server via a HTTP request such as a POST. That this is the case means that malicious users could attempt to overload a server by attempting to upload excessively large amounts of data.

If a WSGI application is not designed properly and doesn’t limit this itself in some way, and attempts to load the whole request content into memory, it could cause an application to exhaust available memory.

If it is unknown if a WSGI application properly protects itself against such attempts to upload excessively large amounts of data, then the Apache LimitRequestBody directive can be used:

LimitRequestBody 1048576

The argument to the LimitRequestBody should be the maxumum number of bytes that should be allowed in the content of a request.

When this directive is used, mod_wsgi will perform the check prior to actually passing a request off to a WSGI application. When the limit is exceeded mod_wsgi will immediately return the HTTP 413 error response without even invoking the WSGI application to handle the request. Any request content will not be read as the client connection will then be closed.

Note that the HTTP 413 error response page will be that defined by Apache, or as specified by the Apache ErrorDocument directive for that error type.

Defining Application Groups

By default each WSGI application is placed into its own distinct application group. This means that each application will be given its own distinct Python sub interpreter to run code within. Although this means that applications will be isolated and cannot in general interfere with the Python code components of each other, each will load its own copy of all Python modules it requires into memory. If you have many applications and they use a lot of different Python modules this can result in large process sizes.

To avoid large process sizes, if you know that applications within a directory can safely coexist and run together within the same Python sub interpreter, you can specify that all applications within a certain context should be placed in the same application group. This is indicated by using the WSGIApplicationGroup directive:

<Directory /usr/local/wsgi/scripts>
WSGIApplicationGroup admin-scripts

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

The argument to the WSGIApplicationGroup directive can in general be any unique name of your choosing, although there are also a number of special values which you can use as well. For further information about these special values see the more detailed documentation on theWSGIApplicationGroup directive. Two of the special values worth highlighting are:


The application group name will be set to the empty string.

Any WSGI applications in the global application group will always be executed within the context of the first interpreter created by Python when it is initialised. Forcing a WSGI application to run within the first interpreter can be necessary when a third party C extension module for Python has used the simplified threading API for manipulation of the Python GIL and thus will not run correctly within any additional sub interpreters created by Python.


The application group name will be set to the value of the named environment variable. The environment variable is looked-up via the internal Apache notes and subprocess environment data structures and (if not found there) via getenv() from the Apache server process.

In an Apache configuration file, environment variables accessible using the 

<span class="pre">%{ENV}</span>

 variable reference can be setup by using directives such as SetEnv and RewriteRule.

For example, to group all WSGI scripts for a specific user when using mod_userdir within the same application group, the following could be used:

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/~([^/]+)
RewriteRule . - [E=APPLICATION_GROUP:~%1]

<Directory /home/*/public_html/wsgi-scripts/>
Options ExecCGI
SetHandler wsgi-script

Defining Process Groups

By default all WSGI applications will run in what is called ‘embedded’ mode. That is, the applications are run within Python sub interpreters hosted within the Apache child processes. Although this results in the best performance possible, there are a few down sides.

First off, embedded mode is not recommended where you are not adept at tuning Apache. This is because the default MPM settings are never usually suitable for Python web applications, instead being biased towards static file serving and PHP applications. If you run embedded mode without tuning the MPM settings, you can experience problems with memory usage, due to default number of processes being too many, and can also experience load spikes, due to how Apache performs lazy creation of processes to meet demand.

Secondly, embedded mode would not be suitable for shared web hosting environments as all applications run as the same user and through various means could interfere with each other.

Running multiple Python applications within the same process, even if separated into distinct sub interpreters also presents other challenges and problems. These include problems with Python extension modules not being implemented correctly such that they work from a secondary sub interpreter, or when used from multiple sub interpreters at the same time.

Where multiple applications, potentially owned by different users, need to be run, ‘daemon’ mode of mod_wsgi should instead be used. Using daemon mode, each application can be delegated to its own dedicated daemon process running just the WSGI application, with the Apache child processes merely acting as proxies for delivering the requests to the application. Any static files associated with the application would still be served up by the Apache child processes to ensure best performance possible.

To denote that a daemon process should be created the WSGIDaemonProcess directive is used. The WSGIProcessGroup directive is then used to delegate specific WSGI applications to execute within that daemon process:

WSGIDaemonProcess www.site.com threads=15 maximum-requests=10000

Alias /favicon.ico /usr/local/wsgi/static/favicon.ico

AliasMatch /([^/]*\.css) /usr/local/wsgi/static/styles/$1

Alias /media/ /usr/local/wsgi/static/media/

<Directory /usr/local/wsgi/static>
<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

WSGIScriptAlias / /usr/local/wsgi/scripts/myapp.wsgi
WSGIProcessGroup www.site.com

<Directory /usr/local/wsgi/scripts>

<IfVersion < 2.4>
    Order allow,deny
    Allow from all
<IfVersion >= 2.4>
    Require all granted

Where Apache has been started as the 

<span class="pre">root</span>

 user, the daemon processes can optionally be run as a user different to that which the Apache child processes would normally be run as. The number of daemon processes making up the process group and whether they are single or multithreaded can also be controlled.

A further option which should be considered is that which dictates the maximum number of requests that a daemon process should be allowed to accept before the daemon process is shutdown and restarted. This should be used where there are problems with increasing memory use due to problems with the application itself or a third party extension module.

As a general recommendation it would probably be a good idea to use the maximum requests option when running large installations of packages such as Trac and MoinMoin. Any large web site based on frameworks such as Django, TurboGears and Pylons or applications which use a database backend may also benefit.

If an application does not shutdown cleanly when the maximum number of requests has been reached, it will be killed off after the shutdown timeout has expired. If this occurs on a regular basis you should run with more than a single daemon process in the process group such that the other process can still accept requests while the first is being restarted.

If the maximum requests option is not specified, then the daemon process will never expire and will only be restarted if Apache is restarted or the user explicitly signals it to restart.

For further information about the options that can be supplied to the WSGIDaemonProcess directive see the more detailed documentation for WSGIDaemonProcess. A few of the options which can be supplied to the WSGIDaemonProcess directive worth highlighting are:

user=name | user=#uid

Defines the UNIX user _name_ or numeric user _uid_ of the user that the daemon processes should be run as. If this option is not supplied the daemon processes will be run as the same user that Apache would run child processes and as defined by the User directive.

Note that this option is ignored if Apache wasn’t started as the root user, in which case no matter what the settings, the daemon processes will be run as the user that Apache was started as.

group=name | group=#gid

Defines the UNIX group _name_ or numeric group _gid_ of the primary group that the daemon processes should be run as. If this option is not supplied the daemon processes will be run as the same group that Apache would run child processes and as defined by the Group directive.

Note that this option is ignored if Apache wasn’t started as the root user, in which case no matter what the settings, the daemon processes will be run as the group that Apache was started as.


Defines the number of daemon processes that should be started in this process group. If not defined then only one process will be run in this process group.

Note that if this option is defined as ‘processes=1’, then the WSGI environment attribute called ‘wsgi.multiprocess’ will be set to be True whereas not providing the option at all will result in the attribute being set to be False. This distinction is to allow for where some form of mapping mechanism might be used to distribute requests across multiple process groups and thus in effect it is still a multiprocess application. If you need to ensure that ‘wsgi.multiprocess’ is False so that interactive debuggers will work, simply do not specify the ‘processes’ option and allow the default single daemon process to be created in the process group.


Defines the number of threads to be created to handle requests in each daemon process within the process group.

If this option is not defined then the default will be to create 15 threads in each daemon process within the process group.


Defines a limit on the number of requests a daemon process should process before it is shutdown and restarted. Setting this to a non zero value has the benefit of limiting the amount of memory that a process can consume by (accidental) memory leakage.

If this option is not defined, or is defined to be 0, then the daemon process will be persistent and will continue to service requests until Apache itself is restarted or shutdown.

Note that the name of the daemon process group must be unique for the whole server. That is, it is not possible to use the same daemon process group name in different virtual hosts.

If the WSGIDaemonProcess directive is specified outside of all virtual host containers, any WSGI application can be delegated to be run within that daemon process group. If the WSGIDaemonProcess directive is specified within a virtual host container, only WSGI applications associated with virtual hosts with the same server name as that virtual host can be delegated to that set of daemon processes.

When WSGIDaemonProcess is associated with a virtual host, the error log associated with that virtual host will be used for all Apache error log output from mod_wsgi rather than it appear in the main Apache error log.

For example, if a server is hosting two virtual hosts and it is desired that the WSGI applications related to each virtual host run in distinct processes of their own and as a user which is the owner of that virtual host, the following could be used:

<VirtualHost *:80>
ServerName www.site1.com
CustomLog logs/www.site1.com-access_log common
ErrorLog logs/ww.site1.com-error_log

WSGIDaemonProcess www.site1.com user=joe group=joe processes=2 threads=25
WSGIProcessGroup www.site1.com


<VirtualHost *:80>
ServerName www.site2.com
CustomLog logs/www.site2.com-access_log common
ErrorLog logs/www.site2.com-error_log

WSGIDaemonProcess www.site2.com user=bob group=bob processes=2 threads=25
WSGIProcessGroup www.site2.com


When using the WSGIProcessGroup directive, the argument to the directive can be either one of two special expanding variables or the actual name of a group of daemon processes setup using the WSGIDaemonProcess directive. The meaning of the special variables are:


The process group name will be set to the empty string. Any WSGI applications in the global process group will always be executed within the context of the standard Apache child processes. Such WSGI applications will incur the least runtime overhead, however, they will share the same process space with other Apache modules such as PHP, as well as the process being used to serve up static file content. Running WSGI applications within the standard Apache child processes will also mean the application will run as the user that Apache would normally run as.


The process group name will be set to the value of the named environment variable. The environment variable is looked-up via the internal Apache notes and subprocess environment data structures and (if not found there) via getenv() from the Apache server process. The result must identify a named process group setup using the WSGIDaemonProcess directive.

In an Apache configuration file, environment variables accessible using the %{ENV} variable reference can be setup by using directives such as SetEnv and RewriteRule.

For example, to select which process group a specific WSGI application should execute within based on entries in a database file, the following could be used:

RewriteEngine On
RewriteMap wsgiprocmap dbm:/etc/httpd/wsgiprocmap.dbm
RewriteRule . - [E=PROCESS_GROUP:${wsgiprocmap:%{REQUEST_URI}}]


Note that the WSGIDaemonProcess directive and corresponding features are not available on Windows or when running Apache 1.3.





一,使用python xx.py运行程序时,加上版本号。比如python3.6 xx.py


yz@yz-<span class="hljs-symbol">pc:</span>~$ sudo su


  1. root@yz-pc:/home/yz# python
  2. Python 3.6.5 (default, Apr 1 2018, 05:46:30)
  3. [GCC 7.3.0] on linux
  4. Type “help”, “copyright”, “credits” or “license” for more information.
  5. >>> exit()
  6. root@yz-pc:/home/yz# python2.7
  7. Python 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
  8. [GCC 7.3.0] on linux2
  9. Type “help”, “copyright”, “credits” or “license” for more information.
  10. >>> exit()
  11. root@yz-pc:/home/yz# python3
  12. Python 3.6.5 (default, Apr 1 2018, 05:46:30)
  13. [GCC 7.3.0] on linux
  14. Type “help”, “copyright”, “credits” or “license” for more information.
  15. >>> exit()
  16. root@yz-pc:/home/yz# python3.5


我们可以使用 update-alternatives 来为整个系统更改Python 版本。以 root 身份登录,首先罗列出所有可用的python 替代版本信息:

  1. #update-alternatives –list python
  2. update-alternatives: error: no alternatives for python

如果出现以上所示的错误信息,则表示 Python 的替代版本尚未被update-alternatives 命令识别。想解决这个问题,我们需要更新一下替代列表,将python2.7 和 python3.6放入其中。

  1. # update-alternatives –install /usr/bin/python python /usr/bin/python2.7 1
  2. update-alternatives: using /usr/bin/python2.7 to provide /usr/bin/python (python) in auto mode
  3. # update-alternatives –install /usr/bin/python python /usr/bin/python3.5 2
  4. update-alternatives: using /usr/bin/python3.4 to provide /usr/bin/python (python) in auto mode

–install 选项使用了多个参数用于创建符号链接。最后一个参数指定了此选项的优先级,如果我们没有手动来设置替代选项,那么具有最高优先 级的选项就会被选中。这个例子中,我们为/usr/bin/python3.4 设置的优先级为2,所以update-alternatives 命 令会自动将它设置为默认 Python 版本。

  1. # python –version
  2. Python 3.5.2

接下来,我们再次列出可用的 Python 替代版本。

  1. # update-alternatives –list python
  2. /usr/bin/python2.7
  3. /usr/bin/python3.5

现在开始,我们就可以使用下方的命令随时在列出的 Python 替代版本中任意切换了。


<span class="hljs-comment"># update-alternatives --config python</span>
















缠中说禅 2006-12-05 11:53:53



缠中说禅 2006-11-29 15:14:38


缠中说禅 2006-12-05 12:04:22



缠中说禅 2006-12-05 12:06:44

[匿名] 外科医生 2006-12-05 11:58:23




缠中说禅 2006-12-05 12:13:42

小明 2006-12-05 12:10:46





缠中说禅 2006-12-05 12:19:26

[匿名] 外科医生 2006-12-05 12:10:50




缠中说禅 2006-12-05 12:23:04

小明 2006-12-05 12:17:51



缠中说禅 2006-12-05 12:25:25

[匿名] 妄语 2006-12-05 12:18:29




缠中说禅 2006-12-05 12:48:32

[匿名] 你的粉丝 2006-12-05 12:36:59




缠中说禅 2006-12-05 12:52:01

[匿名] 想飞的猪 2006-12-05 12:41:48









缠中说禅 2006-12-05 12:53:55

[匿名] CCTV 2006-12-05 12:52:59




小明 2006-12-05 12:54:41

心茫 各位博友注意!




“高抛低吸”,说的轻巧,谁不知道高抛低吸!我做梦都想高抛低吸!但是落实到行动上,你怎么就知道你进入的就是低点? 如果要止蚀,越低越买那不套死?又怎么知道你卖出的就是高点?很多大牛就骑了一小段就下来的惨痛例子还少?



缠中说禅 2006-12-05 12:54:49


缠中说禅 2006-12-05 13:46:42


缠中说禅 2006-12-01 15:02:23



缠中说禅 2006-12-05 21:56:43

[匿名] 你的粉丝 2006-12-05 12:56:56





缠中说禅 2006-12-05 21:58:17

[匿名] 妄语 2006-12-05 13:15:51




缠中说禅 2006-12-05 22:12:54

[匿名] 在路上 2006-12-05 13:52:21





缠中说禅 2006-12-05 22:18:03

[匿名] 笨笨猪 2006-12-05 14:55:34





缠中说禅 2006-12-05 22:19:50

[匿名] 小明 2006-12-05 21:16:43

早上入了000623 追高了,




缠中说禅 2006-12-05 22:23:28













缠中说禅 2006-12-04 12:15:49



缠中说禅 2006-11-29 15:14:38


缠中说禅 2006-12-04 12:17:22


缠中说禅 2006-12-01 12:16:49


缠中说禅 2006-12-04 12:18:41




缠中说禅 2006-12-04 12:25:41

[匿名] 糊涂蛋 2006-12-04 12:24:36




缠中说禅 2006-12-04 12:37:10


2006-12-01 15:02:23


缠中说禅 2006-12-04 12:41:04

[匿名] 糊涂蛋 2006-12-04 12:33:58





缠中说禅 2006-12-04 12:43:34


缠中说禅 2006-12-04 12:46:03

[匿名] 醉酒青牛 2006-12-04 12:43:08




缠中说禅 2006-12-04 12:50:01

[匿名] nn 2006-12-04 12:45:13




缠中说禅 2006-12-04 12:51:18

[匿名] 淡定 2006-12-04 12:49:23




缠中说禅 2006-12-04 12:56:06

[匿名] 外科医生 2006-12-04 12:51:09





缠中说禅 2006-12-04 12:58:07

[匿名] 多多 2006-12-04 12:51:10




缠中说禅 2006-12-04 12:59:43

[匿名] 数女粉丝 2006-12-04 12:53:22




缠中说禅 2006-12-04 13:00:02


缠中说禅 2006-12-04 13:24:23


缠中说禅 2006-12-04 15:02:36

[匿名] 小明 2006-12-04 14:53:36

[匿名] 缠禅 2006-12-04 13:51:34







缠中说禅 2006-12-04 15:12:37

[匿名] 2006-12-04 13:59:22






缠中说禅 2006-12-04 15:17:21

[匿名] 木头 2006-12-04 15:06:16





缠中说禅 2006-12-04 15:21:04

[匿名] YY 2006-12-04 15:18:07




缠中说禅 2006-12-04 15:23:17

[匿名] 瞎鼓捣




缠中说禅 2006-12-04 15:27:58

[匿名] 中间体 2006-12-04 15:24:01

按缠姐的方发资金利用率是不是底虽然安全因为底部的个股上涨开始会很慢有时可能进一步缠绕是不是那种刚突破的个股比较好呢像今天的600832。 这样的话买入法就变了




缠中说禅 2006-12-04 15:35:32


缠中说禅 2006-11-29 15:14:38


缠中说禅 2006-12-04 15:37:38

[匿名] 小明 2006-12-04 15:34:46





缠中说禅 2006-12-04 15:40:10



缠中说禅 2006-12-04 22:53:23

[匿名] 戈石 2006-12-04 19:53:18






緾终禅:2009-03-23 00:04:45