500miles

500miles

这家伙有点懒,还没写个性签名!

  • 财富值2470
  • 威望值220
  • 总积分4940

个人信息

  • 把问题描述清楚

  • 一, 第一个问题, 需不需要把文件导入进来?

    答案是 : 需要!

    但是在各种框架内, 你不会直观的感受到这一点, 因为都实现自动加载了.

    早期__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也提供有自动加载方式)

    具体的标准去查一下资料吧 这里就不说了 已经很啰嗦了

  • 回复了 的回答

    信息太少, 无从下手.

    打log分析吧.

    这种bug真是要命, 头疼.... 只能现在就在整个流程 加上详细的log, 等下次出现再仔细分析吧

  • 2015-11-11 已签到
    连续签到73天,获得了20个金钱
  • 回复了 的回答

    http://www.yiichina.com/question/1160

    这是之前回答过的一个问题, 和你现在遇到的情况一模一样.

    参考那个解决吧.

    那这样我可能就帮不上什么忙了. 只能说 : 验证码是存在session了, 具体原理你也知道,.. 就围绕这个 多调试吧 没其他办法

  • 信息太少, 无从下手.

    打log分析吧.

  • 你说的对, 通常就是异步处理了.

  • 回复了 的回答

    这样子可能轻松生成上千订单

    依赖 mysql count订单量, 在并发情况下 是不可靠的.

    除非你加锁, 针对你这种情况, 需要加表级别锁, 还得是WRITE LOCK, 将会引起性能上的极大隐患, 不推荐.

    一个简单易行 比较讨巧的办法 是做一个原子性的自增计数, 来帮你控制10个订单的量.

    你可以用mysql的自增id特性完成, 他内部维护有轻量的自增锁.

    具体做法是: 新建一张表A, 只要一个自增主键即可; 每次请求 都先插入表A一条空数据, 拿到一个自增id, 判断是否大于10即可;

    针对你这个情况, 应该足以应付了.

    当然 如果使用内存db, 比如redis memcache等, 来实现一个自增计数, 或者一个队列, 就更高效了

    但这玩意和你现在面临的问题毫无关系啊.. 不仅解决不了问题. 还会添油加醋, 变得更不可控....

  • 回复了 的回答

    这样子可能轻松生成上千订单

    依赖 mysql count订单量, 在并发情况下 是不可靠的.

    除非你加锁, 针对你这种情况, 需要加表级别锁, 还得是WRITE LOCK, 将会引起性能上的极大隐患, 不推荐.

    一个简单易行 比较讨巧的办法 是做一个原子性的自增计数, 来帮你控制10个订单的量.

    你可以用mysql的自增id特性完成, 他内部维护有轻量的自增锁.

    具体做法是: 新建一张表A, 只要一个自增主键即可; 每次请求 都先插入表A一条空数据, 拿到一个自增id, 判断是否大于10即可;

    针对你这个情况, 应该足以应付了.

    当然 如果使用内存db, 比如redis memcache等, 来实现一个自增计数, 或者一个队列, 就更高效了

    额 查了一下, 原来php pthreads扩展里面也有提供这个. 你指的应该是这个吧?

总监 等级规则
4940/5000
资料完整度
30/100
用户活跃度
0/100

Ta的关注

0

Ta的粉丝

15

Ta的访客

42