500miles
- 500miles 回答了问题 怎样按照数字升序、字母顺序排列?
把问题描述清楚
- 500miles 回答了问题 namespace use 作用域问题。
一, 第一个问题, 需不需要把文件导入进来?
答案是 : 需要!
但是在各种框架内, 你不会直观的感受到这一点, 因为都实现自动加载了.
早期
__autoload
后来 又增强版spl_autoload
现代框架都是遵循
composer
自动载入标准完成而
composer
的自动加载标准又和namespace
结合了起来, 这个后面补充.二. 第二个问题,
use
的作用域是什么, 有多广?比如 : 同一个服务器上有
A站和B站
,A站下A\a
,B站有B\b
,还可以在B\b.php
里面use A\a
吗?`答案是 : 不知道怎么回答了 = =! 只能说和几个站毫无关系...
在当前请求周期内, 只要先加载到了
A\a
, 那么随后你都可以use A\a
;这和几个项目没关系, 和文件摆放位置没关系
!!! 只和 当前请求内, 你
use
的时候 有没有事先声明并include进来
有关系;如果非要说出作用域? 只能看
每次请求的实际情况
了...三. 补充
在各种现代框架内(遵循了
composer
标准的)一般 只要你
use A\a
; 就能自动加载进A\a
(当然 你确实有声明);并不用小心翼翼的担心 我
use A\a
时候, 有没有include进来呀因为
composer
就是按照namespace
来自动加载类的.当然并不绝对(未遵循该标准的,
composer
也提供有自动加载方式)具体的标准去查一下资料吧 这里就不说了 已经很啰嗦了
这个问题乍一看 觉得很简单... 天天都在用的东西 这有什么好说的?
仔细一琢磨, 要想原原本本的说清楚 还真是不知从何说起.
占坑 晚点有空回答
一, 第一个问题, 需不需要把文件导入进来?
答案是 : 需要!
但是在各种框架内, 你不会直观的感受到这一点, 因为都实现自动加载了.
早期
__autoload
后来 又增强版spl_autoload
现代框架都是遵循
composer
自动载入标准完成而
composer
的自动加载标准又和namespace
结合了起来, 这个后面补充.二. 第二个问题,
use
的作用域是什么, 有多广?比如 : 同一个服务器上有
A站和B站
,A站下A\a
,B站有B\b
,还可以在B\b.php
里面use A\a
吗?`答案是 : 不知道怎么回答了 = =! 只能说和几个站毫无关系...
在当前请求周期内, 只要先加载到了
A\a
, 那么随后你都可以use A\a
;这和几个项目没关系, 和文件摆放位置没关系
!!! 只和 当前请求内, 你
use
的时候 有没有事先声明并include进来
有关系;如果非要说出作用域? 只能看
每次请求的实际情况
了...三. 补充
在各种现代框架内(遵循了
composer
标准的)一般 只要你
use A\a
; 就能自动加载进A\a
(当然 你确实有声明);并不用小心翼翼的担心 我
use A\a
时候, 有没有include进来呀因为
composer
就是按照namespace
来自动加载类的.当然并不绝对(未遵循该标准的,
composer
也提供有自动加载方式)具体的标准去查一下资料吧 这里就不说了 已经很啰嗦了
- 500miles 2015-11-11 已签到连续签到73天,获得了20个金钱
@q573927428 那这样我可能就帮不上什么忙了. 只能说 : 验证码是存在session了, 具体原理你也知道,.. 就围绕这个 多调试吧 没其他办法
- 500miles 回答了问题 突发性的无法更新数据库内容
信息太少, 无从下手.
打log分析吧.
你说的对, 通常就是异步处理了.
这样子可能轻松生成上千订单
依赖
mysql count
订单量, 在并发情况下 是不可靠的.除非你加锁, 针对你这种情况, 需要加表级别锁, 还得是
WRITE LOCK
, 将会引起性能上的极大隐患, 不推荐.一个简单易行 比较讨巧的办法 是做一个原子性的自增计数, 来帮你控制10个订单的量.
你可以用
mysql
的自增id
特性完成, 他内部维护有轻量的自增锁.具体做法是: 新建一张表A, 只要一个自增主键即可; 每次请求 都先插入表A一条空数据, 拿到一个自增id, 判断是否大于10即可;
针对你这个情况, 应该足以应付了.
当然 如果使用内存db, 比如
redis memcache
等, 来实现一个自增计数, 或者一个队列, 就更高效了@bryson 但这玩意和你现在面临的问题毫无关系啊.. 不仅解决不了问题. 还会添油加醋, 变得更不可控....
这样子可能轻松生成上千订单
依赖
mysql count
订单量, 在并发情况下 是不可靠的.除非你加锁, 针对你这种情况, 需要加表级别锁, 还得是
WRITE LOCK
, 将会引起性能上的极大隐患, 不推荐.一个简单易行 比较讨巧的办法 是做一个原子性的自增计数, 来帮你控制10个订单的量.
你可以用
mysql
的自增id
特性完成, 他内部维护有轻量的自增锁.具体做法是: 新建一张表A, 只要一个自增主键即可; 每次请求 都先插入表A一条空数据, 拿到一个自增id, 判断是否大于10即可;
针对你这个情况, 应该足以应付了.
当然 如果使用内存db, 比如
redis memcache
等, 来实现一个自增计数, 或者一个队列, 就更高效了@bryson 额 查了一下, 原来
php pthreads
扩展里面也有提供这个. 你指的应该是这个吧?